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GLOSSARY  OF  ACRONYMS 


ABBREVIATION 

DEFINITION 

AFSATCOM 

Air  Force  Satellite  Communication 

AI 

Artificial  Intelligence 

ASIC 

Application  Specific  Integrated  Circuits 

ASSD 

Autonetics  Strategic  Systems  Division 

ATE 

Automatic  Test  Equipment 

ATLAS 

Abbreviated  Test  Language  for  All  Systems 

ATPG 

Automatic  Test  Program  Generation 

ATRED 

Automatic  Test  Requirement  Document 

ATRD 

Automatic  Test  Requirement  Document 

ATRD 

Automatic  Test  Requirement  Document  Generation 

BILBO 

Built-In  Logic  Block  Observer 

BIT 

Bui 1 t-In-Test 

BIST 

Buil t-In-Sel f-Test 

BITE 

Built-In-Test  Equipment 

CAD 

Computer  Aided  Design 

CADAT 

Computer  Aided  Design  And  Test 

CAE 

Computer  Aided  engineering 

CAMELOT 

Computer  Aided  Measure  of  Logic  Testability 

CEPS 

CITS  Expert  Parameter  System 

CITS 

Central  Integrated  Test  System 

DB 

Data  Base 

DoD 

Depart  of  Defense 

EM 

Electro -mechanical 

EMMA 

Expert  Missile  Maintenance  Aid 

ENG 

Engineering 

FORTRAN 

Formula  Translation 

HILDO 

Highly  Integrated  Logic-Device  Observer 

HITS 

Hierarcnical  Integrated  Test  Simulator 

ID 

Identification 

I  RAD 

Independent  Research  and  development 

ITA 

Interface  Test  Adaptor 

LASAR 

Logic  Automated  Stimulus  and  Response 

LRU 

Line  Replaceable  Unit 

LSSD 

Level -Sensitive  Scan  Design 

MATE 

Modular  Automatic  Test  Equipment 

MSI 

Medium  Scale  Integration 

NSIA 

National  Security  Industrial  Association 

PAWS 

Personal  ATLAS  Workstation 

PRO 

Procedure 

QA 

Quality  Assurance 

RADC 

Rome  Air  Development  Center 

REF 

Reference 

REQ 

Requi rement 

REQMTS 

Requi rements 

GLOSSARY  OF  ACRONYMS  continued 


ABBREVIATION 

DEFINITION 

SCOAP 

Sandia  Control abi 1 ity/Observabil ity  Analysis  Program 

SIM 

Simulator 

SPICE 

Simulation  Program  with  Integrated  Circuit  Emphasis 

SSI 

Small  Scale  Integration 

SRU 

Shop  Replaceable  Unit 

STRAT 

Strategy 

SYSCAP 

System  Circuit  Analysis  Program 

TAD 

TRO  ATLAS  Development 

TDA 

Testability  Design  Aid 

TEST 

Tester 

TISSS 

Tester  Independent  Software  Support  System 

TPS 

Test  Program  Set 

TRD 

Test  Requirement  Document 

TTL 

Transistor-Transistor  Logic 

UUT 

Unit  Under  Test 

VHSIC 

Very  High  Scale  Integrated  Circuits 

VLSI 

Very  Large  Scale  Integration 

VMS 

Virtual  Memory  System 

WP 

Wordprocessor 

PURPOSE  OF  th:  study 


The  purpose  of  this  effort  was  to  investigate 
the  processes  involved  and  develop  an  approach 
aimed  at  the  automation  of  Test  Requirement 
Documents  (TRD),  and  the  incorporation  of  that 
capability  into  computer  aided  design  (CAD) 
processes.  This  effort  was  divided  into  the 
following  tasks: 


°  Survey  current  methods  of  TRD  generation  and  application. 

°  Investigate  various  means  used  by  skilled  engineers  to 
manually  perform  TRD  development  tasks. 

°  Identify  and  assess  the  current  state-of-the-art  automation 
of  TRDs. 

°  Evaluate  and  assess  those  methods  investigated. 

•  Investigate  near  future  and  future  prospects  for 
automating  TRD  generation. 

°  Recommend  a  course  of  action  which  can  be  used  as  a  guide 
for  implementing  a  program  of  transition  to  a  fully 
automated  TRD. 


Automa ted 
TRD 

Generation 


The  program  was  divided  into  two  phases. 

1.  Perform  an  industry  and  government  wide  survey  analysis  to  determine 
current  generation  methods,  application  of  TRDs,  and  to  establish 
the  role  of  the  TRD  in  the  Unit  Under  Test's  (UUT)  development 
cycle.  The  first  phase  also  included  defining  the  manual  methods 
used  for  generating  most  TRDs  and  defining  the  state-of-the-art. 

2.  Tabulate,  reduce  and  summarize  the  results,  to  evaluate  and  assess 
the  various  methods  and  processes  for  application  to  an  automated 
TRD  process,  and  to  create  a  recommended  plan  for  developing  a  TRD 
generation  process  and  a  guide  for  implementing  the  plan. 

The  study  encompassed  the  end-to-end  generation  of  TRDs  required  for  five 
different  areas  of  application:  simple  digital,  complex  digital,  analog, 
hyDrid,  and  electro-mechanical .  The  study  also  included  Unit  Under  Test  (UUT) 
complexities  ranging  from  System  Level  to  Snop  Replaceable  Units  (SRU). 


i 

I 


PROGRAM  ACTIVITIES 


The  program  activities  performed  to  investigate 
all  aspects  of  TRO  generation,  automation,  current 
practices  and  future  prospects,  and  their  results 
were  as  follows: 


Automated 

TRD 

Generation 


Study  Task 


Resul ts/Concl usi ons 


»  Survey 


The  survey  was 
conducted  using  mail, 
telephone,  personal 
contact  and  literature 
search. 


The  majority  of  TRD  developers  used  a 
digital  simulator 

Half  of  the  TRD  developers  use  Computer 
Aided  Engineering  (CAE)  and/or  document 
generators  for  some  portion  of  the 
development 


Investigate  Manual 
Method 


In  this  investigation, 
the  manual  generation 
of  an  analog  LRU  TRD, 
requiring  1500  hours 
to  generate,  was  used 
as  a  baseline  for 
comparison  with 
automation  methods. 


60%  were  not  satisfied  with  the  present 
development  method 

70%  did  not  think  TRDs  were  cost 
effective 

TRDs  are  needed  to  enable  the  AF  to 
obtain  bids  from  TPS  developers 

TRD  automation  has  progressed  rapidly 
for  digital  UUTs  but  little  has  been 
accomplished  for  other  types 


Summary  of  Total  Testing  Requirements 

-  300  hours 
Performance  Tests 

-  400  hours 
Diagnostic  Tests 

-  400  hours 

Abbreviated  Test  Language  for  All  Systems 
(ATLAS)  Procedures 

-  200  hours 

Quality  Assurance  Verification 

-  200  hours 
Total  1 500  hours 


mm 


* 

Study  Task 

- - -  " 

Results 

•  Assess  the  state  of 
the  art  of  TRD 
automation 

Areas  of  automation 
assessed  were  in 
document  generation 
and  fault  simulation. 

Most  digital  TRDs  were  developed  using 
Engineering  Computer  Aids 

Some  analog  TRDs  for  simple  circuits  use 
device  level  simulators 

Remainder  done  manually 

°  Compare  TRD  aspects 
in  the  present,  near 
future,  and  future 

Present 

Near  Future 

Future 

TRD  form 

Paper 

Paper 

Electronic 

format  (based  on 
MIL-STD-1519) 

Interpretive 

Standards, 

No  Electronic 
Compatibility 

Streaml i ned 
Standards, 
Electronic 
Compatibility 

Standardized 

Electronic 

Format 

Timel ine 

After 

Prototype 

Development 

Parallel 

with 

Prototype 

Development 

Parallel 
wi  th 

Prototype 

Development 

Developer 

1 )  Independent 
Contractor 

2)  Logistics 

3) Test 
Engineer 

Designer 

Computer 

Generated 

CAE/CAD 

Schematic 

Capture 

UUT  &  TRD 
Development 

UUT  «  TRD 
Development 

Data  Transfer 
Interfaces 

Wire  List 
Transfer 

Schematic/ 

Drawing/ 

Document/ 

All  Data 

Computer 

Processing 

Technique 

Simulation/ 
Desi gnation 
Generation 

Distributed 

Concurrent 

Data  Bases 


Local 


Company 


National 


SURVEY  RESULTS 


A  literature  search  was  performed  as  part  of  this  effort  and  confirmed 
the  findings  of  the  mail,  telephone  and  personal  contacts  summarized  in  the 
previous  table. 

MANUAL  METHODS  INVESTIGATION 

Investigation  of  tne  Manual  Metnod  required  analyzing  and  dividing  the 
method  into  processes  and  task  had  to  be  defined.  The  process  was  defined  as 
a  group  of  tasks  which  when  combined  and  further  divided  provide  an  unique 
identifiable  activity. 

A  task  was  defined  as  an  activity  by  three  or  less  personnel  using  a 
specific  skill  to  perform  part  of  one  process,  reporting  to  a  single 
functional  group  (such  as  Prepare  Artwork  for  Formal  TRD  Document). 

In  order  to  provide  a  baseline  for  comparison  with  an  automated 
process,  average  time  required  where  determined.  The  Analog  LRU  TRD  was 
selected  because  it  was  representative  of  a  manually  developed  average 
complexity  UUT. 

ASSESSMENT  OF  THE  STATE-OF-THE-ART 

This  task  addressed  a  large  number  of  computer  aids  (programs  and 
tools),  used  for  the  generation  of  TRD  documents.  Automation  was  concentrated 
in  the  simulation,  and  document  generation  areas.  Simulation  is  the  area 
where  duplication  is  most  significant  because  of  the  time  and  resources 
required.  Digital  simulation  is  widely  used  in  the  digital  area  and  has  made 
the  most  advances  in  the  last  10  to  15  years. 

Digital  fault  simulation  is  performed  using  the  parallel,  concurrent 
and  parallel  value  algorithms.  Fault  simulators  for  other  UUT  types  do  not 
exist  and  are  performed  manually.  The  form  and  content  of  a  TRD  using  a 
simulator,  and  one  developed  by  manual  method  differs  in  that  TRD  developed 
using  a  digital  simulators  requires  only  a  performance  flow  diagram  whereas 
non-digita!  TRD  developed  manually  requires  a  detail  flow  diagram.  The 
simulator  performance  and  diagnostic  outputs  are  included  as  a  table 
simplifying  the  flow  diagram. 

COMPARING  THE  PRESENT,  NEAR  FUTURE  AND  FUTURE 

The  investigation  determined  methods  and  the  practicality  of  combining 
the  capabilities  into  an  automated  procedure.  The  survey  analysis  showed  that 
the  TRD,  as  now  defined,  does  not  provide  an  adequate  set  of  verified  data  to 
accurately  estimate  Test  Program  Set  (TPS)  costs.  The  TRD  development  cycle  is 
too  long,  frequently  providing  data  that  does  not  agree  with  the  latest  UUT 
configuration.  In  addition,  the  tests  specified  may  not  be  possible  with  the 
selected  or  available  equipment. 

To  correct  these  conditions,  an  investigation  of  possible  automation  in 
the  near  future  was  performed,  which  centered  on  applying  technology  now 
available,  such  as,  simulation  programs  (HITS,  LASAR,  etc.),  usage  of  common 
data  bases,  document  generators  (TAD,  PAWS,  etc),  or  under  development,  such 
as,  standardizing  ATE,  MATE,  and  analog  and  hybrid  simulators. 


Tne  development  needed  for  the  future  requires  considering  related 
activities  (TPS  development.  Failure  Mode  and  Effects  Analysis  generation, 
etc.)  to  ensure  that  the  automated  TRD  would  provide  a  useful  purpose  in  the 
future  environment,  and  that  the  automated  techniques  investigated  would 
function  effectively  as  part  of  a  larger  automated  process. 


CONCLUSIONS 


The  conclusions  resulting  from  the  program  Automated 

indicate  automation  Is  feasible  and  practical.  TRD 

Generation 


°  Automation  is  feasible  and  practical.  "Island  of  automation" 
exist  which  can  be  integrated  to  provide  an  automated  TRD 
document  generator. 

°  Automation  is  being  applied  to  simple  digital  fault  simulators 
and  specialized  document  generators. 

°  Further  development  of  simulators  is  required  for  analog,  hybrid 
and  electro-mechanical  systems. 

°  Incorporating  techniques  such  as  Expert  Systems  (ES),  Built-in- 
Test  (BIT),  Bui  1 1- In-Test-Equipment  (BITE),  and  Design  for 
Testability  will  enhance  the  automation  of  TRDs. 

°  Improvement  in  the  TRD  process  hardware/software  and  new 

networking  techniques,  provide  diversified  capabilities  for  data 
gathering,  simulation  and  document  generation. 

*  Development  of  TRDs  is  simplified  by  good  testability  design, 
i.e.  MIL-STD-2165. 

"Islands  of  automation"  (such  as  simulators,  specialized  wordprocessor) 
do  exist  which  can  be  interfaced  to  provide  an  automated  TRD  document 
generator.  However,  this  process  can  not  become  completely  automated  until 
the  fault  simulator  becomes  capable  of  automatically  providing  the  necessary 
input  stimulus  to  attain  the  high  percent  detection  required  for  a  TRD. 
Techniques  such  as  Design  for  Testability,  Built-In-Test  (BIT),  Built-In-Test 
Equipment  (BITE)  and  AI  (Artificial  Intelligence)  -  Expert  Systems  -  need  to 
be  fully  applied  before  a  completely  automated  process  can  be  attained. 


RECOMMENDATIONS 


The  program  Identified  a  number  of  recommendations 
which  will  allow  progressive  development  of  an 
automated  process. 


Automated 

TRD 

Generation 


Modify  existing  Mil-Specification 

-  Provide  standardized  format  for  types  of  UUT  as  appendices  to 
MIL-STD-1 51 9 


-  Enhance  requirement  to  include  more  comprehensive  Tneory  of 
Operation 

-  Requirement  for  use  of  MATE  test  equipment  where  applicable 

-  Provide  requirement  for  executable  ATLAS  code  and  ATLAS  test 
flow  diagram 

-  Define  standard  interface  requirement  for  ATRDG  shell 

-  Specify  required  TRD  output  format  to  allow  for  a  standardized 
non-hard  copy  output  (such  as  tape,  disk,  modem,  etc.) 


°  Develop  and  modify  TRD  hardware/software  process 

-  Interface  CAE  networks  with  other  resources 

-  Provide  link  to  a  large  variety  of  commercial  and  government 
simulators  via  global  data  base  networks 

-  Develop  high-speed  main-frame  computer  and  hardware  simulators 
for  simulation  of  large  complex  circuits 

-  Data  base  routine  to  access  logistics,  engineering  and  contract 
administration's  data  bases  (CALS,  etc.) 

-  Develop  software  required  to  achieve  the  specified  interfaces 
to  data  base  and  TRD  output 

-  Further  development  of  simulators  for  complex  digital,  analog, 
hybrid  and  electro-mechanical  UUTs 

-  Define  and  develop  the  executive  programs  to  create  the  ATRDG 

°  Incorporate  emerging  technology 

-  Incorporate  Expert  System  techniques  into  the  ATRDG  shell  and 
simulation  for  data  management,  test  strategy,  resource 
selection,  automatic  pattern  generation  of  analog  and  digital 
(sequential)  circuits 

°  Further  development  of  simulators 

-  Improve  automatic  pattern  generator  to  handle  sequential 
circui ts 

-  Enhance  simulation  capability  to  include  complex  digital, 
analog,  hybrid  and  electro-mechanical 


The  implementation  and  orderly  transition  from  the  present  methods  to 
those  proposed  in  this  report  can  be  accomplished  by  modifying  the 
specification  as  the  first  step.  The  specification  can  be  imposed  in  new 
contracts,  when  feasible,  by  specifying  the  applicable  revision.  The 
recommended  changes  to  the  TRD  specification  are  as  follows: 


1.  Require  a  complete  and  detailed  Theory  of  Operation. 


2.  Require  use  of  a  Modular  Automatic  Test  Equipment 
(MATE)  library'to  identify  possible  ATE  configurations. 

3.  Generate  executable  MATE  ATLAS  code. 

4.  Define  a  standard  electronic  TRD  file  format  for 
incorporation  and  modification  as  a  part  of  the  TPS. 

5.  Define  TRD  development  phases. 

6.  Define  interface  and  output  formats. 

New  computers  and  CAE  stations  are  evolving  rapidly.  To  ensure  automated 
process  development  will  keep  pace  with  equipment  development,  new  processes 
should  be  developed  for  application  on  a  higher  level  system.  The  intent  is 
to  transfer  the  programs  to  a  local  system  when  the  capabilities  exist  at  that 
level.  The  expanded  CAD  workstation  capabilities  are  to  include  the  following: 

1.  Interface  with  remote  data  bases. 

2.  Automatic  parallel  and  distributed  processing. 

3.  Integrated  design  and  TRD  activities. 

4.  Expanded  local  computer  capabilities  and  memory. 

5.  Develop  standard  interfaces  to  simulators  for  all  types  and 
level  of  UUTs. 

6.  Incorporate  TRD  document  generators  in  the  workstation. 

7.  Integrate  an  Expert  System  for  data  base  and  TRD  activities. 

Automated  data  gathering  requires  access  to  source  data  bases.  Access  to 
other  system  data  bases  requires  development  of  interfaces,  communication 
standards,  data  base  resident  software,  and  a  data  access  control  program. 

Among  other  areas,  the  use  of  AI  will  reduce  the  number  of  operator 
interventions  by  examining  the  requirements  and  selecting  the  applicable 
resource  for  accomplishing  the  various  tasks. 

Simulation  exists  for  digital,  some  level  of  analog  and  hybrid.  Except 
for  digital  simulators,  fault  analysis  required  for  TRDs  does  not  exist.  New 
developments  are  needed  to  expand  the  simulation  capabilities.  Work  currently 
under  way  indicates  that  possible  solutions  will  come  from  improvements  in  the 
near  future.  These  improvements  will  occur  in  the  area  of  functional  modeling 
of  complex  devices  and  SRUs,  test  and  hardware  simulations,  mathematical 
representations,  usage  of  a  testability  analysis  approach,  built-in-test,  and 
higher  speed  simulators.  It  is  recommended  that  expansion  of  Test/Design 
Simulation  software  be  made  as  follows: 

1.  Develop  a  resident  program  to  choose  best  available 
simulator. 

2.  Develop  a  standard  device  library. 
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3.  Provide  hierarchical  and  intertechnol ogy  data 
interfaces. 

Due  to  the  evolution  of  engineering  methods,  available  tools,  processing 
power,  and  military  standards,  a  program  should  be  established  that  would 
standardize  and  drive  requirements,  as  well  as,  monitor  industry /DoD  efforts 
toward  automating  the  TRD. 


•1.  INTRODUCTION  AND  SUMMARY 


Tne  object  of  tnis  program  was  to  define  a  program  for  the  Automation  of 
Test  Requirement  Document  (TRD)  generation  and  the  i ncorporation  of  that 
capability  into  the  Computer  Aided  Design  (CAD)  processes. 

Specifically  the  goals  were  to: 

°  Determine  how  the  current  high-cost  and  long  development  period 
required  for  TRD  generation  could  be  reduced  by  automating  the 
process. 

»  Define  methods  to  expand  the  CAD  process  to  include  TRD  generation. 

®  Define  how  to  apply  Expert  Systems,  a  branch  of  Artificial 
Intelligence  (AI),  to  the  TRD  generation  process. 

1 . 1  BACKGROUND 

The  TRD  is  a  document  containing  all  technical  data  required  to  describe 
each  test  to  be  performed  on  a  Unit  Under  Test  (UUT).  Each  test  requires  a 
minimum  of  one  page,  consequently,  TRDs  with  hundreds  of  pages  are  common. 

The  military  establishment  has  not  been  able  to  obtain  consistent  and 
effective  TRDs.  Tne  cost  is  high  and  continues  to  increase  with  the  increase 
in  UUT  complexities.  Tne  cause  of  this  high  cost  can  be  attributed  to  the  TRD 
preparation  being  manpower  intensive. 

Though  digital  simulators  have  been  used  for  years  and  tne  recent  intro¬ 
duction  of  a  TRD  document  generator,  such  as  TRD  ATLAS  Developer  (TAD), 

Personal  ATLAS  Workstation  (PAWS),  etc.,  nas  provided  a  tool  to  assist  in  the 
TRD  generation,  the  process  is  still  very  labor  intensive.  In  other  UUT  types 
such  as  analog,  hybrid  and  electro-mechanical,  the  process  is  performed 
manual ly . 

To  improve  this  condition  it  is  necessary  to  identify  the  tools  available, 
those  in  development,  and  to  formulate  an  implementation  plan.  That  plan  will 
integrate  these  tools  to  automate  the  TRD  generation  process  thus  reducing  the 
cost  and  providing  a  consistent  and  effective  TRD. 

Circuits  are  now  being  developed  using  Computer  Aided  Engineering  (CAE) 
workstations,  personal  computers  and  simulators  that  are  reducing  engineering 
costs  and  providing  convenient  tools  with  applications  to  some  TRD  activities. 

1.2  OVERVIEW 

The  automatic  testing  process  relies  on  an  interrelated  series  of  ele¬ 
ments  to  produce  the  desired  results.  The  TRD  is  the  key  to  transitioning  the 
design  into  an  item  witn  known,  verifiable  performance. 

Figure  1-1  illustrates  the  relationship  of  the  TRD  to  other  test  elements. 


ATE  =  AUTOMATIC  TEST  EQUIPMENT 
TPS  =  TEST  PROGRAM  SET 
TRD  '  TEST  REQUIREMENTS  DOCUMENT 
ITA  =  INTERFACE  TEST  ADAPTER 
UUT  =  UNIT  UNDER  TEST 


Figure  1-1.  ATE/TPS  Overview 


The  Test  Program  Set  (TPS)  provides  the  Test  Program  and  Interface  Test 
Adapter  needed  to  interface  a  UUT  to  the  Automatic  Test  Equipment.  The 
requirement  for  developing  these  items  starts  with  the  TRD,  which  provides  all 
of  the  UUT  test  requirements.  The  Test  Strategy  introduces  Automatic  Test 
Equipment  (ATE)  capabilities  and  optimizes  the  testing.  The  Test  Program  is  a 
software  program  written  in  Abbreviated  Test  Language  for  All  Systems  (ATLAS) 
or  Tester  Language  code,  which  can  be  executed  by  the  ATE.  The  Interface  Test 
Adapter  (ITA)  provides  the  electrical  and  physical  interface  between  the  ATE 
and  the  UUT. 

To  study  the  automation  of  the  TRD  development,  the  process  was  divided 
into  the  activities  illustrated  in  Figure  1-2. 

A  TRD  provides  all  data  needed  to  perform  tests  on  a  UUT  using  ATE.  Data 
(documents,  drawings,  schematics,  wire  lists,  parts  lists,  etc.)  must  be 
obtained  from  a  variety  of  sources  wnich  includes:  Contracts,  Design,  Equip¬ 
ment  Manufacturers,  Test  and  the  customer.  Once  accumulated,  information 
relating  to  operation,  functional,  and  fault  tests  must  be  identified  and 
formatted  into  the  TRD  description  pages.  Functional  test  sequences,  stimuli, 
and  connection  requirements  are  developed  and  checked,  using  some  form  of 
simulation.  Once  a  functional  test  is  defined,  it  will  verify  the  operation 
of  the  UUT;  faults  are  inserted  into  the  simulation,  and  fault  detection  and 
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Figure  1-2.  Simplified  Flow  Chart 


Isolation  tests  are  developed.  Functional  and  fault  test  development  are 
iterative  processes.  Its  function  is  to  development  an  efficient  test  proce¬ 
dure  to  minimize  test  time,  simplify  test  procedures  and  to  minimize  the  test 
equipment  needed.  The  defined  tests  must  be  converted  into  ATLAS  code  for 
eventual  use  on  a  selected  ATE. 

The  program  was  organized  as  shown  in  Figure  1-3. 

SURVEY  ACTIVITIES 

A  number  of  survey  analysis  were  conducted: 

Pre-contract  -  Conducted  to  establish  Rockwell  in-house  capabilities  and 
tools. 

Mail  Survey  -  After  contract  award,  200  questionnaires  were  mailed  to 
obtain  data  from  all  segments  of  the  industry.  Responses  provided  data 
that  when  correlated  with  the  literature  search  established  the 
industries'  state-of-the-art. 

Telephone  Survey  -  Conducted  to  supplement  mail  responses  and  to  obtain 
individual  opinions. 

Personal  Contact  -  Discussions  were  held  with  Daisy,  Teradyne,  Grumman, 
Bob  Cote  Consultant,  Navy,  Harris,  Systec  and  Army  which  provided  a  mix 
of  TRD  users,  tool  developers,  TRD  managers,  and  TRD  developers.  The 
purpose  was  to  obtain  specific  information  concerning  techniques,  plans 
and  concerns. 

Literature  Search  -  Researched  575  articles  related  to  TRDs,  computers, 
workstations ,  software,  techniques  and  evaluations.  The  literature 

confirmed  survey  findings  and  provided  a  basis  for  evaluations, 
assessments,  investigation  and  recommendations. 
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Figure  1-3.  TRD  Automation  Study  Plan 

Process  Investigation  -  A  baseline  of  the  manual  method  process  was 
established  and  was  used  to  evaluate  possible  areas  of  automation.  The 
Analog  LRU  TRD  was  selected  because  it  was  representative  of  a  manually 
developed  average  complexity  UUT.  Methodology  and  time  required  for  the 
manual  method  is  described  in  detail  under  paragraph  2. 2.2. The  major 
elements  within  the  manual  method  process  and  time  required  for  each  are 
1 isted  i n  Tabl e  1 -1 . 


Table  1-1.  TRD  Generation  Steps  Defined  For  Manual  Method 


Part  A  -  Summary  of  Total  Testing  Requirements 


Develop  Contract  Plan 
Gather  Related  Data 
Theory  of  Operation 
Physical  Description 
Electrical  Interface 
Mechanical  Interface 
Special  Equipment 
Special  Tool 
Test  Data 
Boiler  Plate 


Part  B  -  Performance  Tests  and  Part  C  -  Diagnostic  Tests 


Test  Design 

Test  and  Isolation  Strategy 
Detailed  Test  Requirement 


Part  D  -  ATLAS  Procedures 


Create  ATLAS 


Quality  Assurance  Verification 


QA  Provisions 
QA  Validation 


Total  Time 


Tool  Evaluation  -  All  tools  identified  in  the  analysis  were  categorized 
and  evaluated  for  application  to  TRD  generation.  Data  base  listings  and 
matrices  were  prepared  to  expedite  the  evaluation.  Tools  are  divided 
into  categories  according  to  type  UUT. 


State-of-the-Art  Efforts  Identified  and  Assess  the  Processes  and  Tools 
Available  -  Areas  requiring  development,  possible  combinations  of 
capabilities  and  application  of  similar  techniques  were  assessed  to 
arrive  at  the  current,  near  future  and  future  techniques  for  TRD 
development.  By  evaluating  the  information  provided  by  TRD  and  tool 
development  the  current  state  plus  the  near  future  advances  were  defined 
for  each  level  and  type  UUT. 
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1.3  SUMMARY 


There  are  islands  of  automation  for  the  simple  digital  UUT  that  if 
integrated  can  provide  an  automated  TRD  generator. 

The  use  of  a  networked  system  containing  a  large  variety  of  hardware  will 
enable  a  CAE  workstation  to  utilize  network  capabilities.  Automation  of  TRD 
generation  for  all  types  and  levels  of  UUT  is  limited  by  the  on  net  capabili¬ 
ties  and  the  ability  to  interface  the  various  software  programs  needed  for  TRD 
generation. 

Some  specific  results  are  listed  as  follows: 

°  TRDs  are  generated  manually  except  for  simple  digital  UUTs. 

«  TRD  document  generators  are  now  available  such  as  TRD  Atlas  Develop¬ 

ment  (TAD)  and  Personal  Atlas  Workstation  (PAWS).  Tools  of  this 
type  can  be  integrated  into  an  automated  TRD  generator. 

°  Numerous  digital  fault  simulators  have  been  identified.  Great 
progress  and  improvements  nave  been  made  in  the  digital  simulator 
with  the  introduction  of  parallel,  concurrent  and  parallel  value 
list  algorithms. 

o  To  handle  Very  Large  Scale  Integration  (VLSI)  cnips,  functional 
modelling  and  nardware  modelling  has  been  introduced.  Modelling 
language  such  as  Register  Transfer  Language  and  Hardware  Description 
Language  has  made  modelling  of  complex  chips  feasible. 

•  Analog  fault  simulators  do  not  exist  although  simulators  such  as 
Simulation  Program  with  Integrated  Circuit  Emphasis  (SPICE)  and 
System  Circuit  Analysis  Program  (SYSCAP)  can  be  used.  These  pro¬ 
grams  do  not  have  an  automated  fault  simulation  capability  making  it 
very  expensive  and  time  consuming  to  run.  Further  investigation  in 
this  area  is  warranted  to  develop  an  efficient  fault  simulator  that 
can  be  implemented  in  an  automated  TRD  process. 

•  Hybrid  simulators  do  not  exist.  Until  an  efficient  analog  simulator 
is  developed  the  UUT  of  this  type  needs  to  be  partitioned  and 
simulated  independently. 

•  E-M  simulators  do  not  exist.  Very  few  companies  are  involved  in  the 
generation  of  this  type  TRDs.  This  area  requires  further  study  to 
determine  if  developing  a  simulator  will  be  cost  effective  since  no 
information  were  available  in  the  survey  analysis. 

°  The  incorporation  of  Expert  Systems,  a  branch  of  Artificial 
Intelligence,  can  be  made  in  the  following  areas: 

-  Automatic  pattern  generator  of  the  fault  simulator 

-  Test  and  fault  isolation  strategy 

-  Minimize  operator  intervention 


The  recommendation  for  developing  an  automated  TRD  generator  on  a  CAE 
station  was  divided  into  three  areas  of  activity: 

<*  MIL  Specification  change 

-  Needed  to  eliminate  duplication 

-  Better  define  TRD  roles  and  uses 

-  Define  an  electronic  standard  format  for  the  TRD 
Application  of  new  hardware 

-  To  expand  simulation  capabilities 

-  Allow  access  to  information  resident  in  Engineering,  Reliability, 
Logistics  and  Contract  data  bases 

-  Optimize  the  selection  and  utilization  of  networked  hardware 
Develop  techniques  and  software 

-  Which  will  utilize  the  capabilities  of  available  commercial  and 
government  software 

-  Operate  with  minimum  operator  intervention 

-  Provide  the  designer  with  a  TRD  early  in  the  design  cycle. 


2.  DATA  GATHERING 
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The  contract  period  and  tasks  tend  to  naturally  fall  into  two  phases. 
Phase  I  is  that  effort  associated  with  collecting  all  the  necessary  data, 
while  Phase  II  is  the  analysis  and  evaluation  of  this  data  to  develop  the 
recommendation.  Some  data  gathering  and  survey  update  activities  were  per¬ 
formed  in  Phase  II  to  ensure  that  the  study  data  is  as  current  as  possible  at 
the  conclusion  of  the  contract. 

2.1  SURVEY 

The  survey  analysis  phase  provided  an  industry  wide  base  from  which  to 
evaluate  and  assess  all  aspects  of  TRD  generation  and  automation.  CAD/CAE 
systems  were  also  reviewed  to  provide  data  needed  to  determine  the  feasibility 
of  automat-  ing  TRD  activities  on  a  CAD  workstation.  The  survey  effort  was 
conducted  by:  1)  Identifying  personnel  willing  to  participate  in  a  mail 
survey,  develop  and  distribute  the  survey  forms,  categorize  tne  responses  and 
enter  the  data  in  the  data  base  survey  analysis  files.  2)  Conducting  a 
telephone  survey  of  people  willing  to  respond  to  the  mail  survey,  who  failed 
to  complete  the  survey  forms  in  two  months,  and  3)  Conducting  an  interview  of 
people  identified  as  providing  significant  contributions  to  the  mail  and 
telephone  surveys. 

2.1.1  Pre-Contract 


Prior  to  award  of  this  contract,  Rockwell  had  identified  a  need  to  improve 
in-house  TRD  and  TPS  capabilities  and  had  initiated  a  study.  The  results  of 
the  Rockwell  study  indicated  the  need  for  a  data  management  program  to  accumu¬ 
late  and  aid  in  the  evaluation  of  the  large  quantities  of  data  which  would  be 
gathered.  To  provide  this  capability,  a  number  of  commercial  data  base  pro¬ 
grams  were  evaluated,  and  a  program  selected.  This  program,  hosted 
on  an  IBM-XT,  provided  data  manager,  wordprocessor,  communications,  and  a 
spreadsheet  with  graphics.  This  program  was  well  suited  to  this  effort  because 
of  its  ability  to  handle  large  data  files  and  project  processing  features.  A 
project  processing  routine  was  written  to  store  and  tabulate  the  results. 

The  selection  of  this  program  provided  an  experience  base  which  was 
directly  applicable  to  the  Automated  Test  Requirement  Document  Generation 
(ATRDG)  contract.  Rockwell  purchased  software  was  used  to  support  this 
contract.  This  integrated  software  package  was  used  to:  store  in-house 
analysis  data,  prepare  reports  and  status  IR&D  efforts. 

As  a  part  of  tnis  task,  a  Rockwell  wide  survey  analysis  was  conducted  to 
gatner  information  needed  to  determine  what  improvements  in  TRD  computer  tools 
would  be  economical  and  beneficial  to  the  Air  Force. 
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The  TRD  portion  of  the  study  initially  surveyed  several  divisions  of 
Rockwell  to  get  an  accurate  status  of  the  corporation  technology,  tools, 
processes,  and  metnods  currently  in  use. 

A  questionnaire  was  prepared  by  Autonetics  Strategic  Systems  Division 
(ASSD)  engineering  and  logistics  personnel,  which  was  based  on  the  experience 
and  knowledge  developed  on  the  Air  Force  Satellite  Communication  (AFSATCOM), 
Space  Shuttle,  Peacekeeper  and  otner  programs.  The  original  purpose  of  the 
questionnaire  was  to  provide  the  engineering  simulator  development  group  with 
information  needed  to  determine  what  improvements  in  TRD  computer  tools  would 
be  economical  and  beneficial  to  the  Rockwell. 

The  analysis  was  conducted  by  internal  mail  with  telephone  contact  being 
used  to  clarify  questions  and  for  follow-up. 

The  conclusion  and  recommendations  which  resulted,  were  never  published 
due  to  the  termination  of  the  task  upon  receipt  of  the  ATRDG  contract.  The 
data  is  summarized  in  Table  2-1  and  was  combined  with  contract  analysis  data 
for  analysis. 

The  study  provided  experience  in  data  gathering  techniques,  how  to  format 
questions,  how  to  use  the  data  base,  and  how  Rockwell  was  currently  generating 
TRDs.  The  application  of  tools  and  types  of  problems  provided  an  excellent 
base  for  this  study.  The  high  percentage  of  forms  returned  tended  to  indicate 
that  surveys  were  an  excellent  means  of  obtaining  data. 

Full  advantage  was  taken  of  the  diversity  of  activities  and  approaches 
used  by  various  divisions  of  Rockwell.  The  in-house  analysis  influenced  the 
selection  of  questions  to  be  addressed  in  the  contract  survey. 

Responses  to  most  questions  did  not  indicate  specific  areas  needing 
immediate  improvement.  The  most  frequently  mentioned  items  are  listed  in 
Table  2-1,  and  indicate  a  sequence  for  developing  improved  capabilities. 

The  survey  results  indicate  that  Rockwell  uses  manual  methods  for  most 
activities  associated  with  TRD  generation.  The  areas  requiring  improvements 
are:  expanded  digital  capabilities  with  well  documented  users  manuals,  better 
pattern  generation,  a  wider  range  of  models  with  more  user  defined 
parameters.  The  fault  analysis  features  developed  for  engineering  purposes 
are  in  excess  of  those  needed,  and  should  be  de-emphasized  in  favor  of 
improved  run  time  and  fault  isolation.  CAD  and  document  generation  and  data 
base  features  are  needed  to  reduce  manual  efforts  involved.  TRDs  were 
developed  on  a  multitude  of  major  weapon  systems,  thus  providing  a  well- 
rounded  understanding  of  the  TRD  development  process. 


Table  2-1.  In-House  Survey  Results 


Activity 


I  Data  Base 

II  Test  Requirement  Document 
Interface  Description 

III  Flow  Charts 

IV  Test  Data  Sheet 

V  Automated  Test  Program 
Generation  (ATPG) 

VI  ATPG  Features 


Summary  of  Results 


98%  of  the  activity  done  manually 

52%  manually  documented  -  remainder  done  with 
Data  Base  or  Wordprocessor  Programs 

60%  hand  drawn  -  remainder  use  some  type 
drawing  tool  such  as  CAD 

50%  generated  by  hand 

80%  use  some  type  of  simulator  or  pattern 
generator,  all  agree  that  ATPG  saved  time. 

44%  have  used  more  than  one  ATPG/Simulator 

A  -  General 
Digital  Capabilities 
Well  Documented  Users  Manual 
Shared  Data  Base 
B  -  Model  Data 

Large  Transistor-Transistor-Logic  (TTL) 
Library 

Functional  and  Data  Bus  Variable  Model 
Parameters 

C  -  Pattern  Generator 
Digital  Patterns 
D  -  Fault  Analysis 
Fault  Detection 
Concurrent 

Three-State  Fault  Detector 
Analog  High-Rail  and  Low-Rail  Faults 
E  -  Run  Features 

Circuit  Connection  Analysis 
Fault  Collapse  and  Back  Trace 
Restart 
F  -  Output 
Data  Transfer 
CAD  Interface 

Automatic  TRD  Page  Generation 
Replacement  Sequence 
Determination 

Items  of  little  interest  included: 

Analog  Node  Short  Capabilities 

Monte  Carlo  fault  pattern  and  fault 

capabilities 

Power  Supply  ON/OFF 

Automatic  node  naming 

Transportability 

Tester  and  ATLAS  Interfaces 


2.1.2  Mall  Survey 


The  mail  survey  included  identifying  people  to  contact,  determining  what 
questions  to  include  in  the  questionnaire,  organizing  the  resulting  data  and 
determining  what  follow-up  was  appropriate. 

Tne  initial  contact  lists  were  developed  by  obtaining  lists  of  people  who 
had  attended  conferences  and  meetings  on  topics  which  relate  to  TRD 
generation.  These  meetings  included  lists  of  Modular  Automatic  Test  Equipment 
(MATE)  TPS  Standing  Committee,  NSIA  (National  Security  Industrial  Association) 
Integrated  Diagnostics  Working  Group,  JLC-NSIA,  Automatic  Testing  Committee, 
and  TISSS  (Tester  Independent  Software  Support  System)  Committee  listings. 

Telephone  contacts,  preceding  the  mail  survey  analysis,  provided: 

1.  A  method  of  accurately  determining  who  was  involved  in  TRD  activity 

2.  Who  was  able  and  wanted  to  contribute  data 

3.  Who  should  be  considered  for  personal  contact  (trip). 

The  main  points  established  during  the  phone  conversation,  were  which  of 
the  questionnaires  the  person  contacted  was  interested  in  responding. 

The  initial  list  of  500  was  reduced  to  a  mailing  list  of  approximately 
200  by  the  preliminary  telephone  screening. 

The  mail  questionnaire  was  developed  using  the  in-house  questionnaire, 
the  contract  statement  of  work  and  comments  received  from  experienced  people 
in  the  field.  The  number  of  questions  was  felt  to  be  excessive,  due  to  the 
variety  of  disciplines  and  tne  range  of  UUTs;  therefore,  the  questions  were 
divided  into  groups  relating  to  specific  TRD  activities.  This  resulted  in  a 
number  of  short  forms  which  were  sent  to  people  expressing  an  interest  in  that 
particular  TRD  activity. 

Mail  Survey  Form  Development  -  Under  the  heading  of  Considerations,  the 
various  elements  in  Figure  2-1  reflect  factors  used  to  finalize  the  survey 
analysis  forms.  These  considerations  were  divided  into  two  major  pieces  of 
the  survey.  One  was  intended  to  collect  data  regarding  present  techniques, 
while  the  other  was  directed  towards  the  use  of  tools  in  generating  the  TRDs. 


Information  requested  or  that  which  could  be  derived  from  the  analysis 
included: 

°  Role  played  by  the  TRD  in  the  development  cycle.  Determine  if  all 
sections  of  tne  TRD  were  being  developed,  and  how  they  interface 
with  CAD,  TPS  and  ATE. 

Historic  (wny  that  method  was  selected).  Determine  if  the  method 
used  was  related  to  existing  computer  capability,  previous  use, 
commercially  available  tools  or  other  reasons  not  related  to 
effectiveness. 

°  Current  methods  and  resources  used. 

«  Planned  or  in-work  changes  to  the  existing  methods.  Improvements 
considered. 

°  Step  variations  due  to  type  of  UUT.  Variations  in  TRD  caused  by 
different  types  of  UUT  (System,  Line  Replaceable  Unit  (LRU),  Shop 
Replaceable  Unit  (SRU),  etc.). 

°  ATPG  and  simulators  currently  used.  Such  as  LOGOS,  Logic  Automated 
Stimulus  and  Response  (LASAR),  Hierarchical  Integrated  Test 
Simulator  (HITS),  In-house,  etc. 

°  Experiences  with  other  simulators.  Determine  if  preference  was 
based  on  a  wide  base  of  experience. 

°  Are  present  techniques  suitable  for  automation.  Determine  if  any 
attempt  has  been  made  to  modify  the  TRD  generator. 

°  Projected  methods  of  accomplishing  the  task  in  five  years. 

°  Long-term  projection  for  accomplishing  the  task. 

°  If  manual  generation  was  used  -  what  ski 11 -level  and  algorithms  were 
required  and  how  long  did  it  take  to  complete? 

°  Effects  of  MATE,  ATLAS,  ADA  or  ATE  configurations  on  TRDs. 

A  set  of  forms  were  developed  which  divided  the  activity  into  the 
following  categories: 

°  TRD  Developer 

»  TOOL  Developer 

°  User 

°  Management 

°  Engineering 
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A  further  division  was  made  to  reduce  the  size  of  each  questionnaire  by 
dividing  each  of  the  above  categories  into: 

•  Digital  Small 

•  Digital  Large 

•  Hybri  d 

•  Analog 

•  Electro-mechanical 

This  was  done  since  most  of  the  survey  recipients  contacted  in  the 

original  telephone  contact  indicated  they  specialized  in  some  aspect  of  the 
TRD  activity.  It  was  now  possible  to  develop  a  questionnaire  which  was  more 
concise,  and  addressed  the  specific  portion  of  TRD  development  the  recipient 
was  involved  in. 

The  ten  percent  (20  of  200)  response  was  surprisingly  low,  considering 
the  screening  which  had  been  accomplished  with  the  initial  phone  contact. 

The  second  round  of  follow-up  telephone  calls  gave  the  following  results: 

30  out  Still  intended  to  respond  but  had  not  found  the  time.  Most 
of  100  noted  tnat  completing  this  type  effort  had  a  low  priority,  and 
their  workload  was  high. 

70  out  Never  received  the  forms  (lost  in  the  mail), 
of  100 

6  out  Did  not  feel  they  were  involved  or  qualified  in  the  activity 
of  100  addressed  in  the  survey  analysis. 

9  out  Declined  because  of  the  request  to  release  data,  and  either 

of  100  considered  the  information  requested  proprietary,  or  would  not 
state  why  they  would  not  respond. 

An  additional  two  mail  responses  were  received  as  a  result  of  the  phone 
calls.  The  data  received  was  not  sufficient  to  allow  statistical  evaluation, 
but  it  did  provide  an  indication  of  the  state-of-the-art  and  concerns  of 
companies  involved.  The  data  was  tabulated  and  entered  into  the  data  base. 

The  mail  survey  analysis  was  intended  to  produce  information  related  to 
key  questions  which  could  be  categorized  and  sorted. 
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Table  2-2.  Mail  Survey  Responses 


A 


i 

l 


B 


Evaluation  Category 


USER 

1  TRD  User 

2  TRD  Developer 

3  Tool  Developer 

4  Manager 

5  UUT  Engineer  (Test  Points,  etc) 
UUT  TYPE 

1  Electro-mecnanical 

2  Hybrid 

3  Analog 

4  Digital  -  Small 

5  Digital  -  Complex 


C  TIME 

1  Current 

2  Next  Five  Years 

3  Distant  Future 

4  Past 


No.  Responding 


7 

7 

4 

2 

0 

6 

9 

10 

7 

8 


20 

1 

0 

0 


D  TYPE  EFFORT 

1  TRD  Task  (Manual  Methods)  Contains  Series  of  Processes  15 

2  TRD  Process  (State-of-The-Art)  3 

3  TRD  Automation  5 


E  AUTOMATION  APPLICABILITY 

1  CAD/ CAM  1 

2  AI  0 

3  Data  Base  0 

4  LAN  1 

5  Simulation  6 

6  Hand  5 

7  PC  System  3 

8  Wordprocessor  1 

F  RESPONSE 

1  Decl ined  4 

2  Product  For  Sale  (Tools,  Computers,  Software,  Testers)  2 

3  Service  For  Sale  (TRDs,  TPSs,  UUT  Support)  5 

4  Military  5 

5  Commercial  0 

6  Aerospace  6 

G  APPLICABILITY  TO  CONTRACT 

1  High  10 

2  Partial  6 

3  None  6 


2.1.3  Telepnone 

A  telepnone  survey  was  conducted  of  people  still  interested  in  responding 
A  snort  questionnaire  was  developed,  and  30  people  were  contacted.  Ten  of 
those  contacted  responded  to  the  questions.  In  general,  the  results  indicated 
that  most  people  used  some  computer  tools  but  still  classified  their  activity 
as  manual.  Tney  all  felt  additional  automation  was  possible  and  needed.  The 
results  are  summarized  below: 

1.  Most  people  were  involved  with  all  types  of  TRDs  except 
Electro-mechanical . 

2.  The  majority  used  circuit  simulators  with  about  half  using  CAE  and 
Document  Writers. 

3.  Sixty  percent  were  not  satisfied  with  their  present  techniques. 

4.  Seventy  percent  did  not  think  TRDs  were  cost  effective. 

5.  An  average  of  eighty  percent  categorized  their  methods  as  manual. 

6.  Half  thought  TRDs  would  be  eliminated  in  the  future. 

7.  Sixty  percent  tnought  software  tools  were  available  commercial ly. 

8.  About  sixty  percent  used  manual  methods  and  simulators  for 
testability  analysis. 

2.1.4  Survey  Visit  (Trip) 

The  survey  trip  provided  an  informal  contact  with  key  people  active  in 
TRD  related  activities.  The  selection  of  people  contacted  was  influenced  by 
the  following  factors: 

1.  Ability  to  provide  significant  information  relating  to  the 
technology,  future  plans  and  TRD  automation 

2.  Geographical ly  located  in  close  proximity  to  other  companies 
participating  in  TRD  activities. 

3.  Availability  and  willingness  to  spend  a  half  day  discussing  their 
activities. 

The  following  organizations  and  individuals  were  contacted  during  the 

tri  p: 

Daisy  Systems  Corp.,  Los  Angeles,  CA 

Teradyne  Inc.,  Boston  MA 

Grumman  Aerospace  Corp.,  Bethpage  NY; 

Robert  Cote  Consultant,  Franklin  Lakes,  NY; 

NAVAJKENGCEN,  Lakehurst,  NJ ; 

Systec  Corp.,  Stony  Brook,  NY; 

Harris  Corp.,  Winter  Parte,  FL; 

HHB  Systems  Inc.,  Mahwah,  NJ ; 

PM- IPS  Fort  Monmoutn,  NJ 


Those  contacted  performed  TRD  activities  in  the  following  categories: 

TRD  developers 
TRD  users 
Tool  developers 
TRD  managers 

The  general  format  of  meetings  was: 

1)  A  brief  description  of  the  purpose  for  the  meeting. 

2)  A  discussion  on  the  visitee's  involvement  in  the  TRD  activity. 

In  summary,  the  information  gathered  during  the  trip  reflects  the 
following  concerns  and  suggestions: 

1.  TRD  is  needed  to  allow  TPSs  to  be  bid  competitively. 

2.  TRDs  accuracy  and  means  of  verification  must  be  improved. 

3.  TRDs  are  expensive  and  frequently  impose  requirement  need  for  design 
tests  on  the  TPS  developer  and  user. 

4.  TRDs  should  be  developed  as  a  guide,  finalized  and  formally  released 
after  the  TPS  is  completed. 

5.  UUT  developers  should  be  responsible  to  contract  or  develop  the  TPS; 
thus,  eliminating  the  dispute  over  who  is  responsible  for  errors. 

6.  The  division  of  TRD/TPS  content  should  be  on  a  sliding  scale 
depending  upon  the  type  of  UUT  and  ATE. 

7.  TRDs  in  their  present  form  can  be  eliminated  in  an  automated  system. 

8.  HITS  may  not  be  able  to  keep  up  with  the  growth  of  commercial 
simulators  such  as  LASAR  6  and  Computer-Aided  Design  And  Test 
(CADAT),  due  to  amount  of  funding  available  to  support  much 
development. 

9.  TRD  and  TPS  development  contents  overlap,  and  TPS  developers  prefer 
to  get  data  directly  from  UUT  specifications  or  design  data  to 
ensure  information  is  current. 

10.  Automation  of  TRD  has  progressed  to  the  point  of  developing  a  digital 
TRU  from  a  single  workstation,  however,  little  work  has  been  done  in 
the  analog  or  electro-mechanical  (EM)  areas. 

The  results  of  these  contacts  illustrated  the  wide  variety  of  needs  and 
thoughts  as  to  what  functions  the  TRD  should  play,  and  how  it  could  be  used 
effectively. 


2.1.5  Literature  Search 

PuDlished  information  was  easy  to  obtain  and  provided  more  detail,  cur¬ 
rent  data,  and  future  capabilities,  for  the  time  spent  tnan  any  other  survey 
method.  Tne  literature  search  included  TRD  activities,  computer  tools  which 
could  apply  to  TRDs  and  CAD  systems.  All  information  is  categorized  by 
applicable  TRD  taste,  application,  time  availability,  for  tnat  activity. 
Summaries  and  matrices  were  developed  and  provide  rapid  access  to  specific 
data  used  for  conclusions  and  recommendations. 

Approximately  575  articles  (Conference  papers,  sales  literature,  techni¬ 
cal  reviews,  and  journals),  were  reviewed,  categorized,  and  evaluated.  The 
articles  selected  discussed  one  of  the  following  topics: 

TRDs 

CAE/CAD 

Digital  Simulation 
Analog  Simulation 
Hybrid  Simulation 
Electro-mechanical  Analysis 
TPS  Generation 
Data  Base 

Communi cati on-Data 

Computers  with  potential  application  for  TRD  development 

Testability 

ATE 

No  maximum  quantity  of  articles  was  established. 

Information  concerning  historic  advancement  over  the  past  five  years  has 
oeen  obtained  primarily  from  the  literature  search.  The  TRD  activity  is 
quite  dynamic,  and  since  many  engineers  involved  today  were  not  involved  five 
years  ago,  comparing  articles,  written  during  the  period,  has  provided  a  base 
for  this  determination. 

The  maturity  of  digital  circuit  development  has  resulted  in  an  abundance 
of  Dapers  discussing  the  various  methods  for  automating  the  simulation,  test¬ 
ability  analysis,  test  generation  and  TRD  development.  Some  automation  exists 
for  the  activities  listed  in  the  manual  method.  The  major  concerns  are  how  to 
tie  the  different  tools  together,  how  to  provide  a  single  economical  host, 
define  a  point  for  human  intervention  and  input,  how  to  reduce  computer  run 
times,  how  to  expand  the  capabilities  to  complex  digital  circuits,  and  how  to 
interface  with  analog,  E-M  and  other  disciplines. 

Few  articles  were  obtained  on  analog  circuitry.  The  analog  area  is  still 
generally  restricted  to  the  use  of  a  simulator  program,  such  as  SPICE,  which 
is  not  readily  adaptable  to  fault  simulation.  No  articles,  of  any 
significance  relating  to  E-M  were  found. 

The  articles  were  summarized  and  categorized  as  follows: 

Categories  A  thru  G  (Table  2-2)  from  the  Mail  Survey  analysis  were  used 
to  ensure  commonality  of  data  gathered.  Table  2-3,  Categories  H  thru  K  were 
added  to  provide  additional  information  concerning  the  literature. 


The  conclusions  derived  from  the  Literature  Search  were: 

1.  Testability  analysis  and  some  digital  simulation  are  a1 ready  being 
oucompl i shed  on  CAD/CAE  workstations. 

2.  TRDs  are  being  generated  with  computer  programs  specifically 
designed  for  that  purpose  but  generally  have  not  been  integrated 
with  the  simulation  efforts. 


Table  2-3.  Additional  Literature  Sort  Categories 
[Extension  of  Table  2-2] 


Evaluation  Category  No.  Responding 


H  DATA  INPUT 

1  CAD/ CAE 

2  Manual 

3  Communication 

4  Built-In-Test  (BIT)/Bui 1 t- In-Test-Equi pment  (BITE)  Data 

5  Feedback 

6  Foreign  Data  Source 

I  TRD  OUTPUT 

1  Wordprocessor 

2  Graphic 

3  Data  Base 

J  SIMULATOR 

1  Digital 

2  Analog 

3  Hybrid 

4  Electro-mechanical 

5  AI  Tool  for  Test  Program  Generation  (TPG) 

6  AI  Tool  for  Fault  Analysis 

K  LEVEL 

1  System 

2  LRU 

3  SRU 


3.  Digital  simulation  is  widely  used  and  mature,  Analog  simulation  is 
less  mature  and  primarily  supports  low  complexity  devices.  Hybrid 
is  a  combination  of  digital  and  analog  witn  several  possible 
integration  approaches.  Electrc-mecnanical  simulation  data  is 
practically  nonexistent.  The  CAD  capabilities  for  development, 
rotation,  and  inter  Terence  evaluation  coupled  with  an  analog 
simulator  appears  to  be  feasible. 


4. 


Rapidly  expanding  computer,  data  base  systems,  communication  links 
and  special  purpose  hardware  will  provide  a  rapid  access  to  data, 
allow  for  optimized  parallel  process  and  sharing  of  resources  which 
is  essential  in  the  development  of  an  efficient  automated  TRD 
generator. 

5.  Expert  Systems,  a  brancn  of  Artificial  Intelligence,  will  be 
applicable  to  minimize  operator  decisions,  optimize  equipment 
specifications,  select  test  sequences  and  for  similar  tasks  when 
rule  and  procedures  have  been  established. 

All  collected  data  were  placed  in  a  data  bank  using  the  following  format: 


LITERATURE 


L  Ref_No. 

Tvtle 

Author 

Date 

Ref_Doc 

Eval  Cat. 


Literature  sequence  number  used  as  a  reference 

Title  of  article 

Name  of  author 

Date  of  publication 

Reference  documentation 

Code  classifying  article  for  sorting 


Appendix  B  contains  a  complete  listing  of  the  literature  gathered  and 
reviewed 


2.1.6  Summary  of  Surveyed  Data 


CAD/CAE  Workstation 

CAD/CAE  Workstation  such  as  MENTOR,  VALID  and  DAISY  expanded  to  interface 
and  include:  TRD  development,  graphics,  data  bases,  network  access  and  the 
required  software  are  necessary  to  implement  an  effective  design/ATRDG 
station.  By  providing  access  to  data  resident  on  other  systems  the  local 
workstation  acquires  tne  capaoility  of  the  entire  system.  Interface  standards 
will  minimize  the  number  and  types  of  software  programs  required.  Networked 
resources  allow  for  parallel  solutions  on  the  best  suited  resource  available 
for  test  and  design  simulation.  The  following  workstations  wo re  included  in 
tne  investigation: 

Daisy 

Valid 

Auto-trol 

Mentor 

Calma 

Tektronix 

HP 
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The  simulator,  used  in  Part  B  and  C  of  the  TRD,  effort  involves  the 
development  of  model  of  the  UUT.  The  following  steps  are  performed  to  create 
the  circuit  model  if  computer  simulation  is  employed. 

o  Verify  that  models  exist  for  all  the  components  in  the  UUT.  f'odels 
will  have  to  be  generated  for  those  UUT  components  that  have  not  been 
modeled  before. 

o  Use  CAE  schematic  capture  capabilities,  or  create  the  UUT  model  by:  a) 
Assign  numbers  to  all  nodes  (component  junctions)  or  use  wire  list 
inputs,  b)  Assign  reference  designators  (i.e.  Q1 ,  Q2,  R1 ,  ...)  to 
component  models,  c)  Code  tne  UUT  model  by  typing  reference 
designators  together  using  the  node  number. 

o  The  UUT  model  is  then  entered  into  the  computer  via  keyboard,  punch 
card,  or  magnetic  tape  or  CAE. 

Digital 

Numerous  digital  simulators  are  available  and  utilized  in  the  industry 
and  by  the  military:  they  are  effective  on  small  to  medium  scale  IC  and  have 
problems  with  complex  circuits,  microprocessors,  memories,  and  other  complex 
devices.  Many  of  these  devices  require  a  large  and  varying  number  of  clock 
cycles  to  produce  recognizable  outputs;  thus,  complicating  program 
generation.  The  ATPGs  used  today  are  being  applied  successfully  to  simple 
digital  circuitry  of  less  than  100,000  nodes. 

Many  of  these  simulators  are  commercially  available  and  are  used  to 
generate  the  required  data  for  TRDs.  They  include;  LASAR,  LOGOS,  CAPS, 
TESTAIDS,  etc. 

The  design  use  of  simulator  varies  but  include  logic  simulation, 
functional  evaluation,  timing  verification,  worst  case  timing,  stress 
analysis,  fault  and  testability  analysis,  test  point  selection,  design 
verification,  and  simulation/brass  board  tradeoff 

Accurate  simulation  must  consider  the  UUT  types,  since  tne  same  function 
developed  say  in  TTL  will  have  different  characteristics  then  the  same 
function  in  a  CMOS  device  (example:  a  floating  input  to  a  one-input  AND  gate 
will  produce  a  high  output  in  TTL  but  in  CMOS  the  output  state  is  unknown). 

IC  Modeling 

Most  simulator  provide  model  such  as  primitive,  macro  and  functional. 
These  are  software  models  that  performs  the  same  operation  that  the  device 
being  modeled  exhibits.  Some  simulators  (Daisy,  LASAR6,  etc)  provide  the 
capability  of  using  a  hardware  model  which  uses  the  actual  device  being  used 
in  the  circuit  to  simulate  their  operation;  due  to  the  differences  in 
operating  speed  (device  being  real  time  and  the  simulation  being  much  slower) 
a  shell  is  developed  (containing  hardware  and  software),  which  satisfies  the 
input/output  requirements  of  the  device. 


Hardware  modeling,  which  uses  the  actual  device  as  models,  must  operate 
at  real  time  rates  much  faster  than  the  software  simulation  rate.  To  provide 
data  to  the  hardware  model  and  to  use  the  model  outputs  an  interface  shell  is 
built  around  the  hardware  device  to  allow  the  device  to  start  when  all  input 
data  is  available.  When  the  data  is  available  the  interface  (shell) 
conditions,  clocks  and  controls  the  device  and  runs  the  device  at  real  time 
rate.  The  resulting  outputs  are  stored  to  be  provide  to  the  software  when 
needed.  This  procedure  may  require  a  high  initial  model  development  cost  but 
offers  the  advantage  of  simulating  all  possible  input  conditions  including 
those  not  normally  encountered  or  included  in  a  software  model.  This 
technique  avoids  the  dilemma  of  having  to  model  complex  IC  such  as 
microprocessor  which  is  not  fully  documented  and  some  features  considered 
proprietary  preventing  a  complete  software  model  development. 


Good  Circuit  Simulation 


As  circuits  become  large,  simulation  run  times  and  computer  memory 
requirements  become  prohibitive.  To  allow  for  a  large  and  complex  circuit 
analysis,  gates  are  grouped  together  to  form  functional  blocks.  The 
functional  blocks  can  be  modeled  considering  input  and  output,  simplifying 
the  model,  decreasing  simulation  run  time  and  amount  of  data  generated; 
thus,  extending  the  application  of  the  simulator. 


To  allow  users  to  model  devices  most  simulators  use  a  hardware 
description  language  or  register  transfer  language  to  simplify  development  of 
models.  Since  mucn  of  tne  information  required  is  repetitive,  the  device 
model  can  be  developed  using  computer  generated  software.  Standardization  of 
Hardware  Description  Languages  (HDL)  has  been  underway  for  Very  High  Scale 
Integrated  Circuits  (VHSIC)  design  and  CAE  model  development. 


Program  such  as  HITS  provides  a  hierarchical  multi-level  simulation  which 
allow  the  mixed  models,  and  model  swapping.  This  technique  will  allow  to 
simulate  large  and  complex  circuit  in  stages  by  swapping  all  or  part  of  the 
models  in  the  circuit  extending  the  capability  of  the  simulator. 


Propagation  delay  of  device  use  unit-delay  or  multiple  of  the  unit-delay 
or  zero-delay.  In  the  unit-delay  simulation  all  gates  have  the  same 
unit-delay  or  multiple  of  that  delay,  whereas,  in  zero-delay  the  gates  are 
handled  as  an  ideal  switching  element. 


Most  common  states  in  a  digital  simulation  are  1,  0,  HIZ  and  unknown. 
Additional  states  include  drive  levels,  rise  and  fall  states.  The  drive  levels 
are  significant  for  situations  of  drive/bus  contention,  attenuation 
considerations  and  high  impedance  determination.  Numerous  simulators  have 
larger  number  of  states  but  are  transparent  to  the  user. 


Majority  of  the  simulators  use  static  simulation  which  applies  one 
pattern  to  a  digital  circuit,  then  exercizes  the  circuit  until  all  node  have 
reached  a  stable  state,  then  the  data  is  outputted.  There  are  circuits  where 
it  is  not  feasible  to  disable  a  cloctc  line  requiring  a  dynamic  simulator  which 
applies  clock  pulses  and  patterns  to  the  circuit  at  a  simulation  rate  equal  to 
tne  operational  rate.  Tne  fault  signature  is  readily  available  and  stored  in 
a  matrix  for  a  static  simulation  but  is  not  easily  done  for  a  dynamic 
simulation.  Until  a  more  efficient  method  of  storing  dynamic  simulation  fault 
signature  is  developed  static  simulation  will  be  the  prevalent  method. 


SS5 


Fault  Simulation 

Fault  simulation  is  a  very  computer  intensive  task,  consequently  time 
consuming  and  expensive.  The  computational  efficiency  of  the  simulator  is 
dictated  by  fault  analysis  technique,  fault  collapsing,  and  fault  selection 
capabil i ties. 

Fault  analyzers  contained  in  simulation  programs  are  based  on  faulting 
nodes  to  specified  states  (most  commonly  1  and  0),  and  exercising  the  UUT 
until  an  identifiable  fault  signature  has  been  obtained.  Fault  isolation  and 
detection  calculation  are  made  from  the  results  obtained  during  the  circuit 
simulation.  Time  required  to  run  large  boards  is  high,  and  require,  skilled 
engineers  intervention  to  attain  adequate  results. 

The  most  common  fault  analysis  technique  used  is  the  concurrent 
simulation  which  determines  fault  detection  by  propagation  of  a  super  fault 
lists  during  a  single  pass  simulation.  Other  techniques  such  as  parallel, 
concurrent/parallel  (Parallel  Value  List),  deductive  and  serial  are  used.  The 
Serial  technique  is  not  used  for  any  of  the  sophisticated  simulator  since  it 
is  a  very  slow. 

All  commercially  available  simulator  provides  fault  collapsing  to  reduce 
the  number  of  faults  which  must  be  simulated  by  a  factor  of  two  or  greater. 
This  feature  is  very  valuable  in  reducing  the  simulation  cost. 

Another  cost  saving  feature  is  fault  selection  to  allow  the  user  to 
selectively  run  fault  and  to  determine  how  far  the  faulty  behavior  propagates 
to  the  output.  Without  this  feature  the  user  will  need  to  analyze  it's  fault 
propagation  manually.  Most  all  simulators  provide  this  capability. 

Vector  Generation 

Patterns  used  for  digital  circuits  are  derived  in  a  variety  of  ways: 
mockup  tests,  pattern  generators,  which  work  well  for  combinational  circuits, 
engineering  acceptance  test  patterns,  by  hand  or  mathematically  driven. 
Patterns  are  required  for  digital  and  hybrid  UUTs  to  determine  if  the  UUT  is 
functional  and  to  identify  and  isolate  faults. 

Various  algorithms  are  currently  in  use.  Most  start  with  a  random 
pattern  on  data  lines  and  specified  states  on  address  and  control  lines. 
Subsequent  states  are  derived  using  an  algorithm  or  by  monitoring  output  state 
cnanges.  Ineffective  patterns  are  discarded  and  unchanged  and  uncontrollable 
nodes  are  reported. 

Test  vector  generation  strategies  used  to  develop  test  patterns  varies 
from  simulator  to  simulator.  The  following  strategies  are  being  used: 

Path  Sensitization  (D  Algorithm) 

Heuri sties 

Random 

Equation  Generation 

Mix-Manual  Automatic 

Marlett's  Algorithm  (Modified  D  Algorithm) 


Tne  most  coranon  strategy  is  the  path  sensitization  technique  but  tnis 
algorithm  is  very  efficient  with  combinational  circuit  and  has  difficulty  with 
sequential  circuit.  Recently,  technique  to  handle  sequential  circuits  have 
been  introduced  such  as  the  Marlett's  Algorithm  which  is  a  modified  D 
Algorithm  and  tne  H1TEST  program  by  General  Radio  which  uses  expert  system  in 
the  derivation  of  the  vectors.  This  area  needs  further  investigation  and  is  a 
potential  area  for  researcn  and  development. 

The  following  articles  in  Appendix  A  relate  to  Logic  Simulators: 

8,  53,  54,  70,  71,  74,  162,  164,  171,  173,  213,  285,  289,  296,  313,  315, 

318,  323,  325,  388,  390,  412,  426,  545,  557,  559,  561,  570 

The  following  articles  in  Appendix  A  relate  to  Fault  Simulation: 

6,  10,  53,  54,  70,  74,  93,  136,  162,  170,  171,  176,  273,  296,  318,  342, 

351  ,  352,  366,  412,  417,  418,  426 

Analog 

An  analog  type  format  is  required  because  digital  models  consider  states, 
and  are  not  sufficiently  detailed  to  allow  application  to  other  types  of 
UUTs.  SPICE  and  SYSCAP  have  been  used  for  years  to  simulate  circuits  at  the 
transistor  level,  these  programs  are  being  applied  to  higher  level  circuits  by 
developing  functional  models  to  replace  the  transistor  models.  This  type 
model  has  limitations  because  of  the  difficulties  involved  in  developing 
accurate  models.  If  a  standardized  Analog  format  was  established,  models  could 
be  transferred  from  simulator  to  simulator,  reducing  the  model  development 
efforts.  Other  analog  simulators,  such  as  the  Analog  Work  Bench  and  Saber 
offer  faster  simulators  designed  for  use  with  higher  level  UUTs.  No  analog 
simulators  have  an  automatic  fault  simulation  capability. 

The  SYSCAP  program  uses  the  Ebbers  and  Moll  mathematical  model,  whereas. 
Spice  uses  the  Gummel  and  Poone  mathematical  model  for  the  transistor.  Some 
Spice  version  provides  the  capability  to  use  either  one  in  a  simulation. 

Hybrid 

Hybrid  simulation  is  required  for  circuits  containing  analog  and  digital 
functions.  Two  approaches  are  being  used  to  simulate  these  circuits:  1) 

Serial  analysis  where  the  simulators  are  integrated  and  the  simulators 
determines  which  type  solution  is  needed  based  on  the  device  type  and  output, 
and  2)  separate  simulators  where  the  simulation  data  is  developed  in  steps 
alternately  solving  analog  and  digital  portions  of  the  circuit. 

E-M 

Mechanical  and  electronic  simulators  co-exist  on  CAE  workstations  and 
computers  and  simulations  are  run  separately  with  the  operator  providing  data 
to  each  simulation  tool  as  needed.  No  automated  fault  simulation  tool  was 
identified  in  the  survey  analysis. 


TRD  Generators 

TRD  generators,  such  as  PAWS  and  TAD,  provide  a  means  of  producing  the 
TRD  document  and  ATLAS  code  from  data  inputted  by  the  operator. 

2.1.7  Survey  Observations 

The  survey  results  indicated  rapid  advances  are  being  made  in  some  areas, 
and  a  continuing  effort  was  required  to  insure  that  the  recommendations 
consider  data  which  was  published  during  the  early  part  of  the  Prepare  Recom¬ 
mendation  Phase  of  the  contract.  The  mail  survey  results  illustrated  the 
difficulty  in  obtaining  information  directly  from  people  busily  engaged  in 
their  assigned  tasks.  Literature  and  personal  contact  proved  to  be  the  best 
sources  for  information. 

Tne  TRD  generation  is  dictated  by  MIL-STD-1519  Dut  the  results  revealed 
that  each  activity  involved  with  the  TRD  had  some  differing  opinions 
concerning  the  role  of  tne  TRD.  The  following  is  a  list  of  aspects  not 
recognized  by  all  segments  of  the  TRD  community: 

1.  TRD  users  indicate  that  tne  TRD  should  provide  an  accurate  source  for 
all  information  needed  to  test  a  UUT.  The  TRDs  today  frequently  lag 
UUT  design  changes,  do  not  provide  accurate  data  and  contain 
unobtainable  tests  using  the  available  ATE. 

2.  TPS  developers  indicate  that  the  TRDs  frequently  contain  test  which 
check  design  parameters  and  should  not  be  required  for  maintenance  or 
trouble  shooting  type  tests.  These  tests  become  a  requirement  on  the 
TPS  developer  and  increase  costs,  test  program  complexities  and  test 
times.  The  TRD  also  contain  errors  which  must  be  identified  and 
changed  to  insure  that  the  TRD  and  TPS  agrees. 

3.  The  government  agencies  see  the  TRD  as  a  vehicle  which  enables 
competitive  bids  for  TPS  development  thus  reducing  TPS  costs.  They 
also  see  the  TRD  as  serving  as  an  interface  between  the  UUT 
manufacturer  and  the  TPS  developer. 

4.  The  developers  of  computer  aids  see  the  TRD  as  a  document  which  in 
some  present  concepts  represents  an  unnecessary  break  point  in  the 
automation  process.  Tnis  is  because  computer  aids  now  allow  Test 
Program  generation  directly  from  the  simulation  output. 

Tne  tecnnical  mecnanics  of  TRD  generation  vary  depending  upon,  TRD 
developer  sopnistication,  type  and  level  of  TRD  and  the  aid  utilized.  Tne  TRD 
developers  in  general  develop  TRDs  using  the  lower  level  engineers  to  gather 
data,  input  computer  programs,  compile  results  and  perform  simple  analysis. 

The  analysis  and  interpretation  of  data  is  left  to  senior  engineers  and  UUT 
designers,  who  are  experienced  in  the  UUT  function  and  operation.  The  TRD 
computer  tools  are  developed  by  senior  engineers  or  specialists  who  are 
experienced  in  test  and  computer  programs.  The  results  indicated  that  higher 
level  of  automation  used,  the  lower  the  level  of  engineer  required,  and  the 
lower  the  total  cost. 


2.2  INVESTIGATE  MANUAL  METHODS 


2.2.1  TRD  Generation  Tasks 

Test  Requirement  Document  Generation 

TRDs  are  generated  for  different  levels  of  the  UUT.  Levels  of  structure 
above  tne  component  part  level  have  been  divided  into  three  categories:  SRU, 
LRU  and  System.  The  basic  structure  of  the  TRD  remains  unchanged  for  each 
level;  however,  TRD  development  techniques  vary  depending  upon  the  UUT  com¬ 
plexity.  Figure  2-2,  a  generic  flow  chart,  illustrates  the  development  of  a 
TRD.  The  flow  illustrated  depicts  an  existing  small  scale  digital  TRD  process 
which  should  closely  parallel  a  typical  future  flow  for  any  type  UUT.  The 
five  types  of  TRDs  being  evaluated  are  as  follows. 

8  Systems  comprised  of  digital  components  in  the  lower  integration 
scales. 


Systems  comprised  of  digital  components  in  the  higher  integration 
scales. 


o  Systems  comprised  of  analog  components 

•  Systems  comprised  of  digital,  analog,  and  hybrid  components. 

»  Electro-mecnanical  systems 

Tne  complete  list  of  data  required  for  TRD  generation  is  shown  in 
Figure  2-3. 

UUT  Description  Pages 

The  UUT  description  pages  effort  involves  the  generation  of  part  A  of  the 
TRD  in  the  format  specified  by  MIL-STD-1 51 9  and  DI-T-3734A.  The  following  are 
required  to  complete  part  A  of  the  TRD. 

°  Complete  the  Configuration  Data  Sheet  for  listing  all  reference 
drawings  and  specifications  used  to  develop  the  TRD. 

°  Complete  the  General  Design  Data  Sheet  in  the  following  manner: 

1)  Obtain  information  concerning  the  UUT  weight,  special  tools  to 
be  used,  and  handling  requirements. 

2)  Use  the  specifications  to  list  input  power  requirements  and 
tolerances. 

3)  Obtain  from  specifications  and  drawings  any  pretest  procedures 
and  safety  precautions. 

«  Complete  the  Interface  Definition  Sheets  as  follows: 

1)  From  parts  lists  and  connector  data  provide  any  mating 
connector  and  test  point  connector  information. 

2)  Obtain  information  from  specifications  on  special  holding 
fixtures  required  to  test  the  UUT. 

3)  Using  schematics  and  specifications  list  all  pins  with  a 
detailed  description  of  each  pin  function. 

°  Prepare  a  Cover  Sheet,  Approval  Sheet,  and  Revision  Sheet  in  the 
format  specified  by  MIL-STD-1 51 9. 

°  Part  A  sheets  are  then  prepared  by  hand  or  by  using  a  word  processor 

Delivery  of  part  A  of  the  TRD  is  usually  required  at  the  beginning  of  the 
TRD  Simulation  (Part  B  and  C)  to  facilitate  test  circuit  coding. 


Functional  Test  Verification 


The  functional  test  verification  consists  of  comparing  the  simulation 
program  outputs  with  the  functional  test  specification  outputs.  If  the 
outputs  do  not  agree,  errors  must  exist  in  the  UUT  model,  input  signals  or  a 
UUT  design  error.  After  the  errors  are  corrected,  the  simulation  is  rerun  and 
the  process  repeated,  until  the  program  and  specification  outputs  agree. 

Automatic  Test  Pattern  Generation 

An  ATPG  program  is  used  for  pattern  generation  for  digital  UUTs  only. 

The  ATPG  uses  algorithms  to  produce  the  minimum  number  of  patterns  for  each 
input  and  output. 

The  ATPG  is  currently  applicable  to  simple  digital  analysis.  Other 
methods  (hand  and  hot  mock-up)  utilize  engineering-developed  patterns,  such  as 
the  functional  test  procedure  patterns  for  parts  such  as  Programmable  Logic 
Arrays  or  other  Application  Specific  Integrated  Circuits  (ASICs). 

Fault  Simulation 

Simulation  of  faults  is  accomplished,  when  a  computer  program  is  used  by 
faulting  all  active  UUT  nodes  (high,  low  and  open).  The  UUT  output  of  this 
fault-run  is  then  compared  with  the  functional  test  data  to  determine  fault 
signatures.  This  activity  generates  fault  data  including  fault  detection, 
isolation  and  part  replacement  lists. 

Software  Programming 

Fault  signatures  are  obtained  by  monitoring  the  outputs  and  test  points 
with  faults  inserted.  Hand  analysis  is  accomplished  by  signal  tracing  from  a 
fault  to  the  outputs  or  test  points. 


ATLAS  is  a  readable  test  language  which  can  be  converted  or  executed  by 
an  ATE.  The  ATLAS  contained  in  the  TRD  is  not  complete.  It  is  developed 
without  knowing  what  tne  test  instruments  will  be  or  wnat  connections  will  be 
provided  in  the  ATE.  Therefore,  TRD  ATLAS  code  is  considered  non-executable 
and  is  essentially  a  word  description  of  the  test  flow  diagram.  If  the  test 
flow  is  presented  in  the  TRD  the  ATLAS  code  is  largely  a  duplicated  effort. 

Complete  TRD 

Completing  the  TRD  involves  the  following: 

°  Layout  the  Test  Flow  per  the  applicable  functional  test 
specification  [Go  path  only]. 

>  Complete  TRD  Cross  Reference  Sheet.  This  cross  reference  correlates 
the  TRD  tests  with  the  functional  test  specification  tests. 

0  Layout  the  Detailed  Test  Flow  [GO  and  NO-GO  paths].  This  flow 

details  the  testing  philosophy  for  fault  isolation,  and  is  reviewed 
with  the  design  engineer  to  ensure  that  it  adequately  covers  the  UUT. 


®  Complete  tne  Detail  Test  Information  Sheets  by  following  the 
Detailed  Test  Flow. 

•  A  TRD  is  then  processed  through  word  processing  and  the  flows  are 
entered  into  CAD. 

®  The  final  TRD  is  reviewed  by  the  design  engineer,  and  corrections 
made  before  delivery  of  the  document. 

Tha  results  of  the  survey  indicated  thot  there  were  few  differences  in 
the  Manual  Method  use  for  different  types  or  levels  of  KUT.  A  description  of 
the  Manual  Method  was  developed  and  used  as  a  baseline  for  evaluating 
automatic  methods. 

2.2.2  Efforts  and  Times  Required 

The  manual  method  for  TRD  generation  was  divided  into  16  major  steps 
which  were  further  divided  to:  identify  tasks  to  specific  skills,  tasks 
performed  by  tnree  or  less  people,  or  tasks  with  a  single  organizational 
responsibility. 

The  original  proposal  addressed  the  Manual  Method  as  being  different  for 
each  type  and  level  of  TRD,  the  results  indicated  that  there  were  few 
differences  and  tne  Manual  Metnod  could  be  established  as  a  single  baseline 
for  evaluating  all  methods. 

Manually  generated  TKDs  (no  computer  aids)  use  the  method  described  in 
Table  2-4.  If  computer  aids  were  considered  as  a  part  of  the  Manual  method, 
all  combinations  of  computer  aids  used  by  any  company  would  have  to  be 
detailed,  which  is  redundant.  For  this  reason,  the  analog  LRU  TRD  was  used  as 
a  guide  for  generating  the  generic  manual  method.  This  method  does  not  use 
aids  or  unique  processes,  and  for  this  reason  is  applicable  to  all  TRDs. 

The  1500  hours  (in-house  average)  required  to  produce  a  high  quality 
Analog  LRU  TRD  were  used  to  establish  a  base  line  for  comparing  manual  metnods 
to  computer  based  or  automated  generation  procedures.  This  in-house  average 
was  obtained  from  Rockwell's  Logistics  organization  which  has  the 
responsibility  of  developing  TRDs.  The  time  required  and  description  of  the 
16  major  steps  is  listed  in  Table  2-4.  To  show  the  improvement  that  will  be 
made  by  implementation  of  automated  process  in  the  near  future  and  future 
Table  2-4  was  reduced  to  13  major  steps  and  is  give  in  Table  2-5. 

A  simplified  diagram  of  the  TRD  generation  process  is  shown  in 
Figure  1-2.  It  consists  of  6  major  categories  which  are: 


Data  Gathering 

Summary  of  Total  Testing  Requirements  Part  A 
Performance  Tests  Part  B 
Diagnostic  Tests  Part  C 
ATLAS  Procedures  Part  D 
Quality  Assurance  Verification 


This  flow  diagram  and  Table  2-5  will  be  used  to  show  the  area  of 
automation  to  be  implemented  in  the  near  future  and  future  and  tne  hours  saved 
by  the  implementation. 


Table  2-4.  TRD  Generation  Steps  Defined  For  Manual  Method 


Process  Task 


Descri ption 


Develop  Contract  Plan 


Review 

Contractual 

Requirements 


Customer 

Specifications 

Gather  Related  Data 


Available 

Data 


Generate 
Missing  Design 
Data 


Review  all  contractual  instruc¬ 
tions.  Identify  and  obtain 
copies  of  all  customer  imposed 
specifications  and  procedures 
required  for  developing  TRDs. 

Review  the  contractual  require¬ 
ments  and  establish  a  plan  of 
action,  development  schedule  and 
milestone  chart.  These  items 
shall  be  dependent  on  the  UUT 
development  schedule. 

Obtain  all  customer  specifica¬ 
tions  applicable  to  the  contract. 

Prepare  a  list  of  all  UUT  design 
and  requirements  data  needed  to 
prepare  the  TRD. 

Compile  a  list  of  applicable 
drawings  and  specifications. 

Obtain  the  following  design 
documents. 

UUT  Acceptance  test  specification 

UUT  Functional  test  specification 

UUT  Parts  list 

Assembly  diagram 

Subassembly  diagram 

Schematic  diagram 

Wiring  diagram* 

System  and  UUT  Drawings 
System  specification* 

*Not  critical  to  SRU  TRD 
development 

Data  not  readily  available  must 
be  generated.  Contact  the  UUT 
developer  and  request  additional 
information,  or  assist  in 
creating  the  data. 


Related  Design 
Documentation 


Table  2-4.  TRD  Generation  Steps  Defined  For  Manual  Method  (Continued) 


lue 


Process  Task 


Description 


40  Theory  of  Operation 

16  Theory  of 

Operation 


Interpret  the  Theory  of  Operation 
from  a  test  standpoint 

The  Theory  of  Operation  is 
defined  by  the  engineer  devel¬ 
oping  the  UUT.  A  logic  diagram 
can  provide  a  description  for 
more  complex  UUTs,  but  is 
usually  not  critical  to  the  TRD 
devel opment. 


24  Generate  Missing  Data  Data  not  readily  available  must 

be  generated.  Contact  the 
responsible  engineer  and  request 
all  required  information  not 
already  in  hand. 

8  Physical  Description  Description  of  UUTs 

6  Necessary  Data  Obtain  tne  following  physical 

characteristics  of  the  UUT 
incorporate  them  into  tne  TRD. 


Weight 

Handling  requirements 
Safety  requirements 
Power  requirements 

Format  Data  Format  all  the  design  data 

requirements  into  the  MIL-STD 
format. 

Electrical  Interface  Present  all  electrical  interface 

data  required  to  support  the  UUT. 

Get  Data  Obtain  from  the  functional  test 

specification,  schematic  drawing, 
parts  list,  engineering,  and  con¬ 
nector  information  all  required 
electrical  interface  TRD 
information. 


Table  2-4.  TRD  Generation  Steps  Defined  For  Manual  Method  (Continued) 


Val  ue 


Process 


UUT  Connector 
ID 


Pin-Out 

Information 


8  Mechanical  Interface 


Get  Data 


Generate 

Drawings 


Description 


Provide  the  following  UUT  con¬ 
nector  information.  Cross 
reference  the  mating  connector 
data  for  all  connectors.  Iden¬ 
tify  all  test  point  connectors 
from  the  parts  list  and 
functional  test  specification. 

Generate  the  pin-out  requirements 
for  tne  TRD.  Each  pin  must  be 
identified  by  signal  name,  mne¬ 
monic,  and  descriptive  data  suf¬ 
ficient  to  define  each  signal. 
This  information  can  be  obtained 
from  engineering,  functional 
test  specifications  and  the 
schematic  diagram.  Descriptive 
data  shall  contain  the  following 
as  applicable: 

Maximum  wire  length 
Grounding  requirements 
Shielding  requirements 
Wire  of  coax  type 
Minimum  wire  size 
Separation  of  circuits 
Twisted  pair  requirements 
Impedance  matching  load 
requirements 
Signal  characteristics 

Define  all  mechanical  interface 
data  required  for  the  UUT. 

Obtain  from  engineering  the  fol¬ 
lowing  mechanical  interface  TRD 
information.  The  descriptive 
data  for  all  special  mounting, 
holding,  and  support  fixtures. 

Obtain  drawings  of  all  interface 
test  equipment. 
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Table  2-4.  TRD  Generation  Steps  Defined  For  Manual  Method  (Continued) 


Value  Process  Task 


Descri ption 


8  Special  Equipment 


Equipment 

Drawings 


Identify  all  special  test  equip¬ 
ment.  Research  all  items  and 
justify  their  use.  Write  a 
brief  item  description  and 
include  all  UUT  applications. 

Obtain  drawings  of  all  special 
test  equipment  from  engineering. 
The  drawings  should  display  all 
dimensions. 


8  Special  Tool 


8 


5U  Test  Data 


Identify  all  engineering  speci¬ 
fied  special  tools.  Research 
the  application  of  all  tools  and 
justify  their  use.  Write  a  brief 
item  description  and  include  all 
UUT  applications. 

Special  Tool  Obtain  drawings  of  all  special 

Drawings  tools.  The  drawings  should 

display  tooling  dimensions. 

Generate  any  test  procedures 
which  would  assure  proper  test 
conditions. 


40 


1C 


Get  Data  Define  the  general  test  proce¬ 

dures  and  precautions  to  assure 
proper  test  conditions  as  stated 
in  the  functional  test 
specification. 

Format  Data  Format  all  test  data  from  the 

functional  test  specification  to 
provide  a  description  of  the  UUT 
test. 


4  Boiler  Plate 


Generate  TRD  boiler  plate  sheets 
for  the  UUT. 


TRD  Sheets 


Generate  required  boiler  plate 


Table  2-4.  TRD  Generation  Steps  Defined  For  Manual  Method  (Continued) 


Value  Process  Task 


Description 


200  Test  Design 


200  Functional 

Flow  Chart 


400  Test  and  Isolation 
Strategy 

360  Fault 

Simulation 


40  Evaluate 

Resul ts 


Define  the  UUT  end-to-end  test 
in  flow  chart  form. 

Generate  the  functional  flow 
chart  to  graphically  illustrate 
the  end-to-end  test  sequence. 
Arrange  so  as  to  define  the 
progressive  strategy  of  testing 
from  program  entry  to  successful 
completion.  Test  in  each  block 
shall  identify  the  function  and 
nature  of  the  test.  The  testing 
sequence  should  be  similar  to 
that  in  the  functional  test 
specification. 

Develop  a  test  and  isolation 
strategy  for  the  UUT. 

Determine  fault  signature  using 
hand  analysis  by  signal  tracing 
from  fault  to  the  outputs  or 
test  points. 

The  UUT  output  of  the  fault 
simulation  is  then  compared  with 
the  functional  test  output  sig¬ 
nals  to  determine  the  fault  sig¬ 
nature.  This  activity  generates 
all  fault  data  including  fault 
detection,  isolation,  and  part 
replacement  lists.  Fault  sig¬ 
natures  are  obtained  by  monitor¬ 
ing  the  outputs  and  test  points 
with  faults  inserted  and  noting 
difference  from  a  good  circuit 
response. 


Table  2-4.  TRD  Generation  Steps  Defined  For  Manual  Method  (Continued) 


Process 


Detailed  Test 
Requi remen t 


Detailed  Flow 
Charts 


Description 


Generate  the  detailed  test 
requirements  using  the  UUT  test 
and  isolation  data  and  the 
functional  flow  chart. 

Detailed  flow  charts  are  required 
for  all  tests  to  be  performed  on 
the  UUT.  The  detailed  flow  chart 
shall  depict  the  test  flow  and 
UUT  stimul i /response  measure¬ 
ments.  The  patterns  of  each 
detailed  flow  chart  shall  be 
complete  in  that  all  the  proc¬ 
esses,  decisions,  branches, 
parallel  operations  and  exits 
shall  be  identified.  Process 
statements  and  symbol  notation 
shall  be  provided  in  the  detailed 
flow  chart  in  sufficient  detail 
to  define  the  function  tested, 
test  methodology  and  the 
expected/required  response. 

Stimul i/response  tolerance  shall 
be  indicated  and  in  accordance 
with  the  specified  requirements 
of  the  UUT.  Expressions  of 
tolerances  shall  be  consistent. 

In  cases  where  absolute  limits 
are  established,  the  detailed 
flow  chart  shall  indicate  the 
delimiter  required  to  ensure 
specified  UUT  performances. 
Additionally,  a  detailed  flow 
chart  shall  be  prepared  for 
power  up  and  power  down  routines 
plus  other  analog  tests. 
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Table  2-4.  TRD  Generation  Steps  Defined  For  Manual  Method  (Continued) 


Process 


Description 


Detailed  Cross 
Ref. 

A  direct  correlation  shall  be 
maintained  between  the  detailed 
flow  chart  and  the  parameters 
described  in  the  UUT  acceptance 
test  procedure.  Each  acceptance 
test  procedure  paragraph  number, 
functional  test  description, 
detailed  functional  test  number, 
and  related  circuit  elements 
shall  be  listed  in  a  cross- 
reference  list. 

Test  Sheets 

The  detailed  test  information 
sheet  snail  be  completed  to 
furnish  additional  detailed  flow 
chart  data.  Each  sheet(s)  must 
correspond  to  a  specific  block 
on  the  detailed  flow  chart. 

romiat  Data 

Input  and  output  signals 
obtained  from  the  functional 
test  specification  should  be 
referred  to  on  the  detailed  test 
information  sheet  and  included 
as  part  of  the  TRD. 

Create  ATLAS 

Formal 

Document 

Preparation 

Generate  ATLAS  code  from 
detailed  flow  chart. 

Art  Work 
Preparation 

Word 

Processing 
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Table  2-4.  TRD  Generation  Steps  Defined  For  Manual  Method  (Continued) 


ue  Process  Task 


Description 


QA  Provisions 


QA  Validation 


Quality  assurance  will  verify 
that  all  required  TRD  data  is 
created  and  meets  all  customer 
speci fications. 

Inspection  of  Review  the  TRD  and  assure  that 

TRD  all  information,  instructions, 

and  format  requirements  are  met 
as  stated  in  the  contract.  Check 
all  drawings,  specifications, 
and  part  numbers  in  the  TRD  for 
accuracy. 

Quality  assurance  will  evaluate 
all  tests  for  function  and 
accuracy. 

Validate  Test  Prepare  a  validation  test  for 

Plan  each  test  in  the  detailed  flow 

chart.  Verify  each  test  by 
applying  stated  inputs  into  a 
good  UUT  and  comparing  the 
results  with  those  of  the  TRD. 

Test  Equipment  It  is  the  contractors  responsi¬ 
bility  that  acceptable  inspection 
and  validation  facilities  are 
used  to  check  the  TRD.  A1 1 
special  equipment  and  tools 
listed  in  the  TRD  should  be 
utilized  for  quality  assurance 
validation  tests. 

Perform  Test  Perform  validation  of  each  test. 

Record  all  results  and  note 
deviation  to  the  expected  output 
values  stated  in  the  TRD. 

Evaluation  Evaluate  the  validation  test 
results.  If  any  test  fails  to 
meet  test  standards  or  require¬ 
ments  then  the  TRD  must  be 
returned  to  the  developer  for 
correction.  Once  the  TRD  is 
acceptable,  it  can  be  sent  to 
the  procuring  activity  for  final 
review. 


Table  2-5.  Present  TRU  Development  Hour  Breakdown 


Present 


Develop  Contract  Plan 

24 

Gather  Related  Data 

28 

Theory  of  Operation 

40 

Physical  Description 

8 

Elect  &  Mech  Interface 

68 

Special  Equipment  &  Tools 

16 

Test  Data 

50 

Boiler  Plate 

4 

Test  Design 

230 

Test  Isolation  Strategy 

430 

Detailed  Test  Requirements 

202 

Create  Executable  ATLAS 

200 

QA  Provisions  &  Validation 

200 

1500  hours 
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2.3  TOOLS  INVESTIGATION 


The  Application  of  Methods  and  Tools  (Table  2-5),  list  the  steps  identi¬ 
fied  in  the  vertical  axis  and  the  type  tool  which  can  be  applied  to  the  step 
on  the  horizontal  axis.  The  overlaps  and  voids  are  illustrated  in  the  table. 


Table  2-6.  Application  of  Methods  and  Tools 


Table  2-6.  Application  of  Methods  and  Tools  (Continued) 


Function 


Process/Task 


Special  Equipment 
Equipment  Drawings 

Special  Tool 

Special  Tool  Drawings 

Test  Data 
Get  fata 
Format  Data 

Boiler  Plate 
TRD  Sheets 


Test  Design 
Functional 


Flow  Chart 


Test  and  Isolation  Strategy 
Fault  Simulation 
Evaluate  Results 

Detailed  Test  Reqt. 

Detail  Flow 
Detailed  Cross  Ref. 

Test  Sheets 
Format  Data 

Create  ATLAS 

QA  Provisions 

Inspection  of  TRD 


Tool  or  Method 


CAD 


CAE 


SIM 


WP 


ATLAS 


TEST 


DB 


MAN 


X 

X 


X 

X 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


QA  Validation 

Validate  Test  Plan 
Test  Equipment 
Perform  Test 
Eval uation 


No  known  system  combines  those  tools  mentioned  above  into  a  usable 
integrated  program. 

The  TRO  is  currently  used  to  develop  test  procedures  for  UUT  testing. 

For  most  programs  the  TRD  is  developed  after  the  hardware  has  been  designed, 
and  the  engineering  acceptance  test  procedure  completed.  By  introducing  TRD 
development  as  a  part  of  the  design,  simulating  the  UUT  at  two  different  times 
can  be  eliminated.  Eliminating  the  separate  test  simulation  will  shorten  the 
total  development  cycle,  and  reduce  the  rework  needed  to  obtain  required 
testability  levels. 

Tne  tasks  defined  as  tne  Manual  Metnod  were  compared  to  the  available 
automated  functions  to  determine  which  portions  of  the  effort  could  now  be 
done  witn  computer  tools.  Analysis  of  tne  data  indicated  that  automation  was 
concentrated  in  the  simulation,  engineering  and  document  generation  areas. 

Each  of  tne  above  areas  of  automation  is  applied  independently,  which  results 
in  duplicated  simulation  activities  by  the  designer  and  the  TRD  developer. 
Simulation  is  widely  used  for  digital  circuits  and  occasionally  for  analog; 
other  areas  seldom  use  simulators.  The  form  and  content  of  a  TRD  using  a 
simulator  and  one  developed  by  manual  metnods  is  different  in  the  fault 
detection  and  isolation  procedures.  Mil -Specifications  and  contracts 
requirements  frequently  vary  with  type  and  level  UUT. 

2.4  ASSESSMENT  OF  THE  STATE-OF-THE-ART 

Recognizing  the  fact  that  analysis  techniques  for  design  and  maintenance 
are  different  but  related;  the  Identification  of  the  state-of-the-art  included 
tools  currently  being  used  for  TRD  development.  Electro-mechanical  TRD 
automation  has  received  very  little  attention,  and  application  of  a  modified 
analog  simulator  in  conjunction  with  the  mechanical  CAD  is  expected  to  provide 
the  needed  capabilities.  No  company  contacted  indicated  development  of  an 
El ectro-mechanical  TRD  generator 

The  following  TRD  generation  topics  were  reviewed: 

Hardware  requirements 
Software  features 
Interact! ve/Batch 

Digital,  Analog,  Hybrid,  Testability  and  EM  simulators 
Model  Library 

Fault  detection,  isolation 
Document  generation 
Data  base 
TRD  generation 
Artificial  Intelligence 

The  state-of-the-art  computer  tools  identified  in  the  survey  analysis  are 
listed  in  Appendix  C. 


Significant  changes  in  tne  state-of-the-art  occurred  during  1986, 
resulting  in  a  re-evaluation  and  modification  of  the  tools  listed  in 
Appendix  C. 

Some  of  these  tools  are  primarily  used  as  design  tools;  they  are  listed 
to  provide  a  capability  which  is  needed  for  an  automated  TRD  generator  and  is 
not  otherwise  available.  Tools  used  for  analysis  by  both  test  and  design 
engineers  are  applied  at  different  times  during  the  development  cycle 
resulting  in  duplicate  efforts. 

Data  Base  listings  and  four  matrices  (Digital,  Analog,  CAE  Workstations, 
and  AI),  consisting  of  key  items  were  prepared.  The  following  conditions  were 
noted: 

The  composite  state-of-the-art  represents  an  overall  capability  which 
contains  overlaps  and  voids. 

Tools,  methods  and  techniques  in  existence  resulted  from  individual 
companies  developing  the  most  cost  effective  approach  with  available 
resources. 

Differences  in  computers,  programming  resources  and  contract  requirements 
influenced  the  area  automated  and  the  extent  of  the  automation. 


3.  EVALUATION 


3.1  EVALUATION  OF  METHODS 

Automation  of  TRDs  has  resulted  from  the  need  to  reduce  costs  and  improve 
quality.  For  these  reasons  the  high  cost,  labor  intensive  activities  were 
addressed  first.  The  development  in  the  areas  of  digital  simulation,  document 
generation  and  ATLAS  were  automated.  Until  1986,  little  had  been  done  to 
standardize  or  interface  computer  tools  in  a  workstation  environment. 

Table  3-1  illustrates  the  major  activities  and  lists  the  present  merits  and 
drawbacks  of  the  methods  in  common  use. 


3.2  ASSESSMENT  OF  METHODS 

The  data  base  contains  items  gathered  during  the  Survey  phase  of  the 
contract.  This  data  was  assigned  sequential  numbers  and  filed  in  the  order 
received.  Tne  data  base  lists  key  elements  and  a  summary  for  each  data  item. 
Data  was  sorted  and  evaluated,  and  the  need  for  additional  detail  identified. 
To  provide  tne  needed  detail  in  an  easy  to  use  format,  four  matrices  were 
developed.  The  matrices  contained  data  base  items  that  were  judged  to  satisfy 
tne  basic  requi rements  of  an  automated  process  (ie.  compatible  hardware  and 
software,  user  aDle  to  modify  input,  output  and  control  of  the  software, 
language  common  witn  otner  needed  capabilities). 

The  areas  of  primary  interest  were  cost,  value,  compatibility,  resource, 
effectiveness,  technology  limits,  and  CAD  applicability.  Data  base  items 
sometimes  discussed  specific  issues  which  had  to  be  related  to  a  complete 
description  of  a  method  before  an  evaluation  was  possible. 

When  seven  or  more  data  base  items  discussed  the  same  topic,  they  were 
listed  in  a  matrix  for  comparison  with  items  listed  in  other  matrices.  By 
using  a  matrix,  it  was  possible  to  categorize,  compare  and  analyze  information 
contained  in  the  articles.  The  articles  usually  discussed  a  key  feature  of  a 
system.  Frequently  it  was  necessary  to  group  information  from  several 
articles  in  order  to  obtain  a  composite  of  the  systems  capabilities. 

The  matrix  (Appendix  B)  was  divided  into  major  categories  (Digital, 
Analog,  CAE/CAD  Workstations  and  AI)  within  each  category.  From  the  matrix 
it  was  possible  to  compile  a  more  complete  description  of  the  key  methods. 
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Table  3-1.  Merits  and  Drawbacks  of  Methods 


Activity 

METHOD 

MERIT 

DRAWBACK 

DATA 

GATHERING 

MANUAL 

Able  to  gather  all  types 
and  form  of  data  from  all 
sources 

Labor  intensive 

Data  management  and 
interpretation  difficult 

CAE/CAD 

Provides  current  design 
data 

All  required  data  not 
available 

Interface  program  needed 

DATA  BASES 

Cost  effective 

Current 

Limited  amount  of  data 
available 

Needs  interface  program 

TRD 

PAGE 

DEVELOPMENT 

MANUAL 

Format  adaptable  to  all 
types  UUT 

Optimized  layout 

Time  consuming 

Variable  formats 

CAE/CAD 

Rapid  Flow  diagram  and 
schematic  development 
Mechanical  design 
Deliverable  prints 

Mixed  text-graphics 

Same  type  and  page  for 
data  input  done  manually 

Usually  stand  alone 

Special  hardware 

DOCUMENT 

GENtRATOR 

Data  entered  once 

Flow  diagrams  and  ATLAS 
generated 

Consistent  format 

Limited  interface 

Operator  input 

FUNCTIONAL 
AND  FAULT 
SIMULATION 

MANUAL 

Mixed  mode  analysis 
Optimized  pattern 

No  model  development 

Time  consuming 

Incomplete  analysis 
Inaccurate 

CAE/CAD 

Schematic  capture 

Analog,  Digital  and 
Mechanical  done 
separately 

Good  model  variety 

Limited  analysis 

Not  primarily  intended 
for  test 

Limited  model  detail 
Proprietary  software 

COMPUTER  High  speed,  accurate 
SIMULATION  Separate  Analog/Digital 
hardware  and  software 

Good  model  library 

Rapid  circuit  development 

Time  consuming  programs 

Proprietary  and 
i ncompatible 

QA 

VERIFICATION 

MANUAL 

Independent  verification 

Time  consuming 

COMPUTER 

SIMULATION 

Aid  in  verification 

Requires  models  and 
circuit  code 

Items  in  the  matrices  were  assigned  a  Characterization  Number.  The 
Characterization  Number  aided  in  the  determination  of  the  most  suitable 
combination  of  processes  required  for  each  of  the  five  types  and  the  three 
levels  of  UUTs  being  considered.  The  Characterization  Number  was  used  by 
sorting  digit  groups  to  obtain  a  list  of  relate  item. 

The  data  contained  in  the  matrices  was  used  to  assess  data  and  to  prepare 
reconmendations. 

The  survey  data  indicates  that  existing  TRD  generation  programs 
accomplished  multiple  tasks,  and  possessed  overlapping  capabilities. 
Furthermore;  these  programs  were  written  in  different  languages,  operated  on 
different  computers,  and  were  not  easily  modified  or  segmented  by  the  user. 

NOTE:  Items  are  not  listed  in  the  same  order  as  shown  in  the  (Automatic) 
Application  Code  description.  All  digits  within  ()  refer  to  the  Application 
Code.  When  sorting  for  Application  Code,  LASAR  6  would  appear  on  four 
different  Application  Code  sorts  (Manual  Data  Entry,  Circuit  Simulation, 
Workstation  and  CAE/CAD  Interface).  Manual  Application  Code  Numbers  are  shown 
for  Automatic/Manual  comparison  purposes  only. 

Features  and  capabilities  of  the  surveyed  methods  were  compared  to  the 
requirements  of  TRD  generation  for  each  UUT.  Model  algorithms,  cost 
considerations,  necessary  resources,  effectiveness  of  the  approach  and 
technological  limits  were  evaluated  empirically.  Comparison  of  costs,  delay 
time  and  skill  levels,  required  for  utilization  provided  a  method  for 
determining  the  optimum  features  for  each  type  UUT.  The  assessment  considered 
the  impact  of  incorporating  the  metnods  or  parts  of  methods  identified  into 
CAD.  The  configuration  of  the  CAD  system  and  compatibility  of  operating 
systems  were  included  in  the  assessment. 

Prior  to  1986  digital  simulation  activities  could  be  divided  into  five 
general  areas  of  activity: 

1.  CAD/CAE  system  -  Primarily  concerned  with  the  design  and  development 
of  electronic  units 

2.  Simulation  and  pattern  generation  -  Design  tools  used  to  verify  the 
design  and  adapted  for  the  testability  analysis  required  for  TRDs 

3.  TRD  document  generators  -  Provided  documentation  of  test  flow 
diagrams,  generic  ATLAS  programs,  part  replacement  data,  functional 
and  fault  test  sequences,  from  manual  keyboard  inputs 

4.  Artificial  Intelligence  -  applied  to  system  analysis  to  provide  the 
additional  knowledge  and  reasoning  to  improve  testability  and  designs 

5.  Improved  computers  and  hardware  -  the  development  of  faster,  larger 
capacity  computers  and  hardware/software  simulators. 


In  1986,  the  five  general  areas  were  combined  into  automated  processes, 
either  by  expansion  of  existing  capabilities  (such  as  Teradyne)  or  by 
combining  the  capabilities  available  from  several  companies  (such  as  HHB  & 
Factron).  The  main  thrust  has  been  to  develop  the  test  program  on  a 
workstation  whicn  had  CAD  capabi 1 ities.  Test  program  development  on  a  CAD 
workstation  nas  resulted  in  by-passing  the  TRD.  Since  the  TRD  was  not 
included  in  tne  CAD  developed  Test  Program;  it  is  necessary  to  transfer  data 
to  a  TRD  generator  (such  as  TRD  ATLAS  Development  (TAD)  or  Personal  ATLAS 
Worxstation  (PAWS)),  to  complete  the  process.  The  drawback  to  this  type 
automated  process  is  tnat  it  usually  produced  test  programs  for  a  specific 
commercial  tester.  Considering  the  impact  of  the  1986  improvements, 
determining  the  future  need,  the  use  of  the  TRD  becomes  a  critical  element  in 
evaluation  and  recommendation  of  the  development  of  an  automated  TRD  process. 
It  is  apparent  that  the  TRD  must  be  changed  to  eliminate  duplicated  and 
unnecessary  data;  it  must  perform  an  essential  function  as  a  part  of  the  TPS. 
Definition  of  the  future  TRD  will  relate  the  development  cycle  of  the  TRD/TPS 
to  the  development  of  the  UUT  and  the  ATE. 

Schematic  capture  of  engineering  data  on  a  CAD/CAE  system  for  TRD 
development  has  been  accomplished  where  the  data  was  originally  generated  on 
the  CAE  workstation. 

Most  CAE  workstations  provide  a  simple  functional  analysis,  limited 
testability  analysis,  and  wire  list  outputs.  In  most  cases  data  can  be 
transferred  to  other  computer  programs  through  a  manufacturer-developed 
interface  program. 

The  digital  simulation  programs,  such  as  HITS,  run  on  larger  computers 
and  provide  accurate  simulations  of  SRUs  and  LRUs.  Simulation  outputs  include 
fault  detection,  fault  isolation,  faulty  component  tables,  testability 
calculations,  and  test  patterns  and  sequences;  all  of  which  can  be  included  in 
tne  TRD  and  the  ATLAS  program.  The  small  and  medium  digital  area  is  the  most 
automated  of  the  areas  included  in  tne  study.  However,  the  following 
capabilities  are  not  universally  available:  CAE  to  simulator  data  transfer, 
simulator  feedback  to  the  CAE,  improved  automatic  pattern  generation,  and  a 
simul ator-to-TRD  wordprocessor  interface. 

Larae-scale  digital  automation  is  being  considered  at  the  part  level  in 
the  TISSS  program.  This  program  is  using  existing  simulators,  and  large 
functional  models  for  simulation.  The  technique  may  be  applicable  to  large- 
scale  digital  UUT  simulation,  and  should  be  analyzed  after  completion  of  the 
TISSS  contract.  The  need  for  this  level  of  simulation  is  recognized,  and  is 
being  worked  by  a  number  of  companies. 

The  feasibility  of  automating  complex  digital  UUTs  will  require 
additional  development  in  the  areas  of  functional  and  logic  simulation, 
reducing  computer  run  times,  pattern  generation,  model  generation,  hardware  in 
active  simulation  and  system  interfaces. 


Automated  analog  TRP  generation  has  not  been  used  for  the  following 
reasons: 

1.  Acceptance  of  current  manual  methods 

2.  Complexity  of  analog  functional  models 

3.  Requirements  for  serial  analysis 

4.  Excessive  computer  run  time 

5.  Skill  level  of  personnel  required 

Previous  approaches  required  expanding  the  capabilities  of  analog  design 
simulators,  adding  functional  modeling  capabilities,  and  converting  output 
formats.  The  results  were  excessive  computer  run  times,  outputs  that  required 
skilled  engineering  evaluation,  complex  model  development,  and  transcription 
of  data  into  a  form  acceptable  for  the  TRD. 

Two  companies.  Analog  Design  Tools  and  Analogy,  have  developed  analog 
workstations;  however,  they  have  not  included  automatic  fault  detection  and 
isolation. 

Hybrid  TRD  development  is  accomplished  by  hand  or  by  combining  the 
results  obtained  from  separate  analog  and  digital  simulations.  The  only 
exception  is  tne  use  of  a  Hybrid  simulator  on  several  programs  by  Rockwell. 
This  simulator  is  considered  to  be  proprietary  and  still  in  the  development 
phase. 

Combined  simulation  required  for  nybrid  UUTs  is  possible.  However,  the 
analog  simulations  tend  to  slow  the  digital  analysis.  Due  to  need  for  serial 
analysis,  this  application  is  slower  than  parallel  or  concurrent  simulation. 

The  state-of-the-art  in  Electro-mechanical  TRD  development  is  related  to 
hybrid  simulation  in  that  both  analog  and  digital  electrical  signals  may  be 
involved.  Mechanical  simulation  involves  physical  units  of  measure,  which 
generally  can  be  simulated  using  analog  simulators.  TRDs  of  this  type  are 
generated  by  hand,  but  may  use  the  tools  listed  in  the  hybrid  description. 
Development  of  an  automated  process  probably  will  not  be  practical  until  a 
good  hybrid  simulator  exists. 

The  state-of-the-art  as  viewed  from  a  variety  of  complexity  standpoints 
(System-LRU-SRU),  tends  to  divide  into  two  categories:  tool  which  can  be  used 
for  all  types  and  levels  of  TRDs,  and  tools  which  must  be  developed 
specifically  to  support  the  unique  requirements  of  the  UUT.  The  current  trend 
is  to  expand  the  SRU  tools  and  techniques  to  include  all  but  the  complex 
LRUs.  System  level  and  complex  LRUs  use  computer  programs  which  analyze 
control,  stability,  safety  and  functionality.  These  commercially  available 
tools  were  developed  for  the  system  design  engineer  to  theoretical ly  analyze 
the  system  operation,  and  perform  a  top  down  system  development.  Few  people 
were  found  who  have  performed  system  design,  and  have  also  developed  TRDs. 


4.  ASSESSMENT  OF  THE  TRD  PROCESS 


4.1  NEAR  FUTURE  PROSPECTS  FOR  AUTOMATION 

Automation  of  the  various  process  was  investigated  to  determine  feasible 
approaches  for  combining  the  known  and  expected  new  TRD  generation  tools. 
Compatibility  with  CAE  workstations,  and  the  amount  of  operator  participation 
were  two  of  the  key  characteristics  considered  for  each  tool. 

The  recent  trend  appears  to  be  toward  a  workstation  combining  the  design 
and  verification  activities  on  a  dedicated  hardware/software  system.  Examples 
of  systems  which  have  accomplished  this  are  systems  offered  by  Daisy,  Mentor 
and  Valid.  These  systems  offer  capabilities  for  simple  circuit  design,  design 
test  and  verification,  testability  analysis  and  physical  circuit  development 
involving  multilayer  boards  or  substrates.  Expanding  these  capabilities  for 
simple  digital  TRD  development  requires  developing  software  which  will  provide 
all  the  capabilities,  currently  available  on  a  number  of  computers,  on  a 
single  workstation.  The  main  concern  from  a  utilization  standpoint  is  the 
execution  time  required  for  TRD  development  which  will  reduce  time  available 
for  the  design  related  tasks  listed  above.  Complex  Digital,  Analog,  Hybrid 
and  Electro-mechanical  present  additional  problems  requiring  development  of 
both  hardware  and  software  to  automate  the  TRD  process  on  a  workstation. 

Impact  of  Test  on  Design  -  BIT,  BITE  and  BIST  all  add  additional 
circuitry  to  tne  UUT  to  provide  a  method  for  establishing  and  monitoring  the 
functionality  of  the  UUT.  This  circuitry  aids  in  the  test  required  by  tne 
TRD.  Tne  use  of  tnis  circuitry  aids  in  providing  continuity  of  failure  data 
from  the  system  test  to  the  individual  UUT  test  by  providing  a  common  monitor 
at  all  levels.  Utilization  of  BIT,  BITE  or  BIST  requires  that  the  circuits  be 
powered,  interfaced,  and  tested  by  the  ATE.  Use  of  these  built-in  circuits 
may  reduce  or  eliminate  some  of  the  ATE  equipment  normally  required.  Use  of 
these  features  in  TRDs  is  relatively  new,  and  very  few  articles  were  found 
which  describe  applications  of  this  kind.  The  incorporation  of  these 
capabilities  should  become  commonplace  in  the  next  five  years.  This 
incorporation  of  UUT  based  tests  on  the  TRD  process  will  require  a  method  to 
extract  test  data  from  the  UUT  and  utilizing  this  data  for  analysis  on  the 
ATE.  The  TRD  must  incorporate  test  procedures  for  these  circuits  and  make 
test  decisions  based  on  all  possible  data  obtained  from  the  circuit, 
simulation  of  test  circuits  must  be  included  to  establish  the  credibility  of 
the  UUT  test  data.  The  decision  to  use  or  reject  UUT  data  should  defined  by 
the  TRD  and  if  possible  implemented  automatically.  This  process  will  add 
complexity  to  the  TRD  and  increase  the  amount  of  testing  required  for  a 
particular  type  UUT. 

Developments  by  CAE/CAD  manufacturers  to  provide  complete  design 
capabilities  on  a  workstation  has  resulted  in  transporting  software  to  common 
computer  systems,  such  as,  the  VAX  and  APOLLO  computers.  Companies  such  as 
Fairchild  and  HHB,  have  developed  workstations  which  provide  capabilities 
interfaced  to  testers.  The  "islands  of  automation"  are  becoming  complete 
processes  linked  together  on  computers,  which  have  data  bases,  tester 
interfaces,  communication  programs,  network  capabilities  and  high  speeds. 
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Outputs  available  from  the  CAE  design  data  base  should  include  connect  list, 
parts  list,  theory  of  operation,  interface  descriptions,  environmental 
requirements,  input  signal  and  power  specifications.  Some  of  this  data  is  not 
currently  incorporated.  Since  simulation  is  a  key  area  in  the  development  of 
an  automatic  TRD  generator,  a  gap  is  created  in  the  the  automated  process  for 
all  but  digital  simulation.  Analog,  Hybrid  and  Electro-mechanical  simulators 
are  few,  and  those  that  do  exist  do  not  provide  for  automatic  fault  simulation 
required  for  the  TRD.  Design  simulators  such  as  SABER,  and  Analog  workbench 
require  expansion  to  include  fault  capabilities  before  an  automated  process 
will  be  available.  Analog  simulators  such  as  SPICE,  and  System  Circuit 
Analysis  Program  (SYSCAP)  are  intended  for  design  at  a  low  complexity  level. 
Application  of  these  analog  programs  would  require  developing  models  of 
complex  devices,  and  intensive  computer  analysis  (days  to  weeks  depending  upon 
circuit  complexity). 

Significant  progress  is  being  made  in  fields  related  to  TRD  automation. 
The  study  of  the  process  indicated  that  the  data  included  in  tne  TRD  should  be 
changed.  Two  possibilities  exist:  1)  the  TRD  be  changed  to  include  only  UUT 
description,  and  all  other  activities  be  performed  as  a  part  of  the  TPS,  or  2) 
the  TRD  be  changed  to  include:  a  complete  detailed  Theory  of  Operation, 
executable  MATE  ATLAS  code,  a  list  of  MATE  test  equipment  capable  of 
performing  the  test,  and  an  Interface  Test  Adapter  (ITA)  connection  list. 

With  the  advances  in  tools  and  the  automation  of  the  TRD,  the  second 
possibility  appears  to  be  the  most  cost  effective.  Most  capabilities  needed 
to  accomplish  the  automation  exist  or  are  in  the  planning  stages.  Interfaces 
to  a  variety  of  sources,  and  sharing  of  resources  will  require  development  of 
new  controls  and  techniques  to  insure  successful  operation  without  interfering 
with  other  activities  such  as  design. 

The  recommendations,  resulting  from  this  study,  allow  for  the  development 
of  an  automated  TRD  generator  by  modifying  the  TRD  and  TPS  Mil -Specifications, 
to  redefine  the  role  of  both  activities,  and  by  using  a  software  control 
program.  The  control  program  will  provide  and  control  application  of  AI,  Data 
Bases,  all  types  of  Simulators,  Wordprocessors  and  Communication  programs  to 
the  best  suited  resources  for  the  particular  workstation  activity  being 
performed.  Additional  developments  are  needed  in  the  areas  of  computer 
hardware,  and  simulation  programs  before  a  completely  automated  system  is 
real ized. 

Simple  Digital  circuits  are  already  being  developed  on  workstations,  the 
areas  requiring  improvement  are  data  base  interfaces  and  automated  TRD 
generator  inputs.  The  evolutionary  process  for  progressing  from  the  Present 
to  tne  Near  Future  and  the  Future  will  be  to  develop  new  specifications,  apply 
higher  capacity  equipment,  develop  data  base  interfaces  and  TRD  generator 
input  routines. 

Complex  Digital  Systems  will  evolve  from  the  existing  technology  with  the 
adaptations  of  system  level  simulators,  hardware  models  and  hardware 
simulators.  Recently  announced  hardware  advances  will  tend  to  enable 
development  and  simulation  at  a  local  level.  Development  of  the  TRD  on  a 
workstation  will  be  accomplished  by  adding  the  TRD  generator  to  the 
workstation  and  interfacing  with  data  bases,  testers,  hardware  and  model 
simulators.  These  tasks  can  be  accomplished  in  the  near  future  with  existing 
or  anticipated  tools. 
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The  Analog  system  requires  extensive  development  in  the  areas  of  complex 
simulation  and  fault  analysis.  Systems  on  the  market  and  proposed  for  the 
near  future  do  not  satisfy  these  shortcomings.  Signal  generation  for  analog 
circuits  are  usually  generated  by  hand,  automatic  generation  will  require 
analysis  of  the  functional  requirements  and  tne  tolerances  associated  with 
each  input. 

Tne  Hybrid  system  remains  a  combination  of  analog  and  digital  systems. 
Development  of  an  automated  system  requires  all  of  the  items  listed  in  the 
analog  and  digital  systems  plus  a  means  of  interfacing  the  two  capabilities. 
The  near  future  capabilities  will  be  limited  to  mathematical  simulations  and 
simple  circuits. 

The  Electro-mechanical  system  is  similar  to  the  hybrid  problem  except 
mechanical  and  electronic  characteristics  must  be  translated  to  interact. 

The  conclusion  derived  from  the  analysis  are  illustrated  in  Figure  4-1, 
Table  4-1  and  Table  4-2.  Figure  4-1  shows  the  automation  that  will  occur  in 
the  near  future  and  Table  4-1  shows  the  reduction  in  TRD  development  hours 
compared  to  the  manual  method  of  generating  TRDs.  Table  4-2  illustrate  the 
hardware/software  which  will  be  required  for  the  near  future. 


Table  4-1  Near  Future  TRD  Development  Hour  Breakdown 


Present 


Develop  Contract  Plan 
Gather  Related  Data 
Tneory  of  Operation 
Physical  Description 
Elect  &  Mech  Interface 
Special  Equipment  &  Tools 
Test  Data 
Boiler  Plate 
Test  Design 

Test  Isolation  Strategy 
Detailed  Test  Requirements 
Create  Executable  ATLAS 
QA  Provisions  &  Validation 


Manual 

Future 

24 

20 

28 

16 

40 

16 

8 

4 

68 

8 

16 

8 

50 

50 

4 

4 

230 

200 

430 

300 

202 

28 

200 

200 

200 

150 

Table  4-2  Near  Future  Hardware/Software  Requirement 


Hardware  Configuration  Software  Configuration 


1. 

VAXstation  II 

a.  Hi -resolution  color 

1 . 

VMS-ws 

graphic  monitor 

2. 

Mentor  program 

b.  16  MB  RAM 

c.  210  MB  hard  disk 

d.  Ethernet  controller 

3. 

ATRED  program 

e.  Mouse/Tablet 

4. 

DECnet 

2. 

Color  plotter 

5. 

RJE  emulator 

3. 

SNA  gateway 

6. 

SPICE  simulator 

4. 

Modem 

7. 

HITS  simulator 

8. 

CAE/CAE  program 

4.2  FUTURE  PROSPECTS 


Selection  of  possible  techniques  and  programs  for  future  applications 
required  considering  new  approaches  to  unresolved  problems.  Developing 
techniques  for  simulating  complex  UUTs  is  one  of  the  key  unresolved  issues. 

The  application  of  programs  similar  to  testability  analysis  programs,  such  as 
SCOAP  could  provide  rapid  analysis  by  eliminating  the  need  to  check  each  nodes 
performance  for  functional  and  fault  conditions;  however,  development  of  test 
patterns  or  input  signals  for  use  on  tne  ATE  do  not  currently  result  from  this 
type  analysis.  Further  investigation  into  the  behavior  of  functional  models 
and  circuits  is  needed  to  resolve  these  conditions.  The  limitation  of 
developing  an  Analog/Digital/Electro-mechanical  hybrid  simulator  appears  to  be 
restricted  to  serial-circuit  solution  approaches.  The  time  required  to  solve 
complex  circuits  serially  is  prohibitive.  The  alternate  solution  is  to 
develop  and  interface  specialized  simulators  which  will  interactively  and 
concurrently  solve  portions  of  the  circuit.  To  effectively  perform  this 
function  a  control  program  must  be  developed  which  will  select  the  proper 
resources  and  and  combine  the  results. 

New  computer  hardware  needed  to  provide  a  variety  of  capabilities  and 
high  speed  can  be  provided  by  a  network  of  capabilities  used  as  needed  rather 
than  developing  a  system  specifically  designed  to  provide  TRD  generation 
capabilities.  This  approach  will  allow  TRD  developments  for  all  types  and 
levels  UUT  to  be  developed  on  any  CAE  workstation  available  on  the  network. 


Figure  4-2  shows  the  area  of  automation  that  will  be  required  for  a  fully 
automated  process  for  the  future.  Table  4-3  illustrates  the  reduction  in 
development  hours  in  relation  to  the  manual  method  and  the  near  future 
processes.  Typical  hardware  needed  to  develop  such  a  system  is  illustrated  in 
Table  4-4.  Approximate  costs  are  estimates  and  do  not  indicate  current  costs 
of  equipment  listed  in  the  figure. 

Requirements  to  reach  the  future  configuration  of  each  type  UUT  are: 

1)  The  future  of  the  simple  digital  will  require  integrating  the 
capabilities  into  tne  complex  digital  system  by  standardizing  model  interfaces 
and  languages  to  enable  model  swapping  to  insure  that  detailed  analysis  is 
available  when  needed. 

2)  The  future  complex  digital  system  will  require  the 
standardization  of  interfaces  and  controls  to  enable  allocation  of  tasks  to  a 
variety  of  linked  capabilities.  The  workstation  will  select  the  optimum 
resource  for  the  task  at  hand,  divide  the  tasks  and  control  parallel 
processing  of  the  tasks.  Data  will  be  returned  to  the  local  station, 
organized,  stored  and  and  outputted  with  minimum  operator  participation.  This 
can  be  accomplished  by  developing  a  shell  program  which  incorporate  AI 
techniques  and  provides  a  framework  for  the  incorporation  of  new  capabilities 
as  they  become  available. 
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3)  Automatic  generation  of  analog  TRDs  will  require  developing  an 
input  stimulus  generator  which  will  be  capable  of  providing  signals  variable 
tnrough  the  specified  tolerances.  The  identification  of  output  changes  caused 
by  the  input  must  be  evaluated.  Future  application  of  AI  techniques  to  signal 
generation  is  necessary  to  resolve  this  problem. 

4)  Fault  analysis  and  complex  circuits  will  require  developing  a 
new  approach  to  simulation,  possibly  the  adaptation  of  engineering  system 
design  techniques  or  testability  analysis  approaches. 

5)  A  generic  solution  to  integrate  all  types  and  levels  of 
electro-mechanical  UUTs  is  possible  in  the  future,  by  using  a  shell  program 
all  needed  resources  will  be  available  at  any  workstation  in  the  network. 


Table  4-3  Future  TRD  Development  Hour  Breakdown 


Present 

Manual 

Near 

Future 

Future 

Develop  Contract  Plan 

24 

20 

8 

Gather  Related  Data 

28 

16 

8 

Theory  of  Operation 

40 

16 

16 

Physical  Description 

8 

4 

4 

Elect  &  Mech  Interface 

68 

8 

8 

Special  Equipment  &  Tools 

16 

8 

8 

Test  Data 

50 

50 

24 

Boiler  Plate 

4 

4 

4 

Test  Design 

230 

200 

100 

Test  Isolation  Strategy 

430 

300 

200 

Detailed  Test  Requirements 

202 

28 

28 

Create  Executable  ATLAS 

200 

200 

60 

QA  Provisions  &  Validation 

200 

150 

130 

1500  hours 

1004  hours 

598  hours 
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Table  4-4  Future  Hardware/Software  Requirement 


Hardware  Configuration 


Software  Configuration 


Advanced  general  purpose 
supermicro  computers 

a.  Full  CAE/CAD  function 

b.  Full  networking  down 

to  record  locking 

c.  300  dpi  color  graphics 

monitor 

d.  Video  input 

e.  Voice  input 

f.  Tablet  input 


1.  Operating  system 

a.  Full  networking 

for  mixed  vendors 

b.  Multi-tasking 

c.  GOOD  user  interface 


2.  CAE /CAD  system 


3.  DoD  Security 


Printer 

a.  Color  laser  page  printer 

b.  Plotter 

c.  High  speed  laser 


4.  ATRD  program 


Satel 1 ite /microwave  comm  link 
to  world  wide  parts/module 
data  bases 


4.  Super  FAST  crunchers  for 

real-time  analysis  and  fault 
simulation 


jsy 

m 
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RP 
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Printers  and  plotters: 

More  tnan  one  type  of  printer/plotter  will  be  required.  LASAR  printers 
are  OK  for  small  page  text  and  graphics.  But  plotters  will  be  needed  to 
output  large  schematic  and  detailed  flow  diagrams  from  the  design  or  logistics. 


Laser  printers: 
Color  Plotters: 


$4,500.00  (Fast,  heavy  duty,  graphics+text) 

$15,000.00  (4'wide,  unlimited  length,  floor 

standing) 


Micro  Computers  (8-16  bit): 

The  small  computer  allows  a  limited  use  distributed  processing.  The 
local  CPU  is  not  powerful  enough  to  run  large  simulation  in  a  timely  manner. 
The  small  computer  can  be  hooked  up  (via  a  network  or  some  type  of 
communication  line)  to  a  larger  system  and  have  the  completed  simulation  set 
back. 

Cost:  $5,000  (min  640K  memory,  30MB  hard  disk,  PGA  with  multi-scan 
moni tor) 

Supermicro /mini  computers  (32  bit): 


The  supermicro  has  the  power  to  run  large  simulations  locally,  and  the 
graphics  to  be  a  complete  CAE/CAD  work  system.  The  communications  and  CPU 
power  combined  witn  integrated  networking  operating  system  allow  the 
supermicro/mini  to  be  a  fully  cooperating  member  of  a  larger  network. 

Cost:  $1 2,000-up  (3MB  memory,  140MB  hard  disk,  Ethernet,  19"  color 

monitor,,  Graphics  @  1024x1024  resolution, 
floating  point  hardware) 

Supermini  computers  (32  bit): 

The  supermini  can  be  the  base  CPU  type  in  a  network  of  supermicros.  The 
main  data  bases  can  be  accessed  here  and  large  simulation  (batch)  may  be  send 
here.  The  more  powerful  this  system  the  better  the  entire  network  will  do 
overall.  These  systems  can  be  stacked  as  needed  when  the  demand  requires. 

Cost:  $350,000  (68MB  memory,  8  Gigabyte  disk,  Ethernet,  Array 

processor ) 


5.  GUIDE  FOR  IMPLEMENTATION 


5.1  BASIS  FOR  IMPLEMENTING  CHANGES 

The  investigation  of  the  near  future  and  far  future  was  conducted  by 
defining  the  specification  and  application  changes  that  were  necessary  to 
overcome  the  criticisms  expressed  during  the  survey.  The  major  criticisms 
expressed  below,  represent  the  concerns  of  different  groups,  TRD  Users, 
Developers,  Military,  and  Tool  Developers. 

1.  TRD  users  indicate  that  the  TRD  should  provide  an  accurate  source 
for  all  information  needed  to  test  a  UUT.  The  TRDs  today  frequently 
lag  UUT  design  changes,  do  not  provide  accurate  data,  and  contain 
unobtainable  tests  using  the  available  ATE. 

2.  TPS  developers  indicate  that  the  TRDs  frequently  contain  tests  which 
check  design  parameters,  and  as  such  are  too  stringent  for 
maintenance  or  trouble  shooting  tests.  These  tests  Decome  a 
requirement  on  the  TPS  developer,  increase  costs,  test  program 
complexities  and  test  times.  The  TRD  also  contains  errors  which 
must  be  identified  and  changed  to  ensure  that  the  TRD  and  TPS  agrees 

3.  The  government  agencies  see  the  TRD  as  a  vehicle  which  enables 
competitive  bids  for  TPS  development  thus  reducing  TPS  costs.  They 
also  see  the  TRD  as  serving  as  an  interface  between  the  UUT 
manufacturer  and  the  TPS  developer. 

4.  The  developers  of  computer  tools,  see  the  TRD  as  a  document  which  in 
some  present  concepts  represent  an  unnecessary  break  point  in  the 
automation  process.  This  is  because  computer  tools  now  allow  Test 
Program  generation  directly  from  the  simulation  output. 

5.2  RECOMMENDED  CHANGES 

From  these  comments  the  following  changes  to  MIL-STD-1519  specification 
and  the  methods  used  were  defined  which  would  possibly  eliminate  the  condition 

1.  Automate  TRD  development  on  a  CAE  station  thus  allowing  the  design 
engineer  to  produce  the  TRD  with  minimum  additional  effort. 

2.  Expand  existing  CAE  data  bases  to  include  all  items  needed  to 
develop  the  TRD. 

3.  Modify  the  TRD  function  and  output  to  consider  ATE  capabilities  to 
ensure  that  realizable  tests  were  defined. 

4.  Identify  and  omit  design  verification  parameters  and  tests  which 
need  not  be  performed  in  the  test  intended  to  verify  function 
operation  or  fault  tests. 

5.  Provide  the  TRD  on  a  specified  type  of  electronic  media,  such  as 
magnetic  tape,  to  the  TPS  and  Tool  developer  for  necessary  updates 
and  modification. 


6.  Define  a  phased  development  cycle  for  the  TRD  that  parallels  the  UUT 
life  cycle  allowing  additions  to  the  TRD  to  occur  once  the  data  is 
availaole  from  the  UUT  development  cycle. 

7.  Provide  a  minimum  TRD  content  {including  a  well  defined  Theory  of 
Operation)  wnen  released  to  obtain  quotes  for  TPS  development. 

8.  Verify  the  accuracy  and  completeness  of  the  TRD  when  released  for 
TPS  quote  and  when  completed. 

9.  Establish  the  TRD  as  an  integral  portion  of  the  TPS  to  provide  all 
needed  UUT  test  information  and  character!' sties. 

The  present  mechanics  of  TRD  generation  vary  depending  upon  TRD  developer 
sophistication,  type  and  level  of  TRD,  and  the  tool  utilized.  However,  most 
TRD  are  developed  using  lower  level  engineers  to  gather  data,  input  computer 
programs,  compile  results  and  perform  simple  analysis.  The  analysis  and 
interpretation  of  data  is  left  to  senior  engineers  and  UUT  designers,  who  are 
experienced  in  the  UUT  function  and  operation.  The  changes  proposed  below 
propose  that  through  automation  it  will  be  possible  for  the  design  engineer  to 
perform  the  TRD  task  with  minimum  impact  on  design  productivity. 

The  TRD  generation  steps  identified  in  Table  2-5  were  analyzed  to 
determine  the  type  of  effort  required  and  automation  category  which  might  be 
applicable  to  each  task.  The  analysis  shown  in  Table  5-1  was  based  on  the 
data  gathered  during  the  survey  and  the  literature  search.  Table  5-1  is  a 
simplification  of  Table  2-5  showing  the  steps  required  for  TRD  generation 
under  tne  title  "Function";  now  the  step  is  performed  under  "Type  of  Task"; 
and  under  "Category"  the  automation  process  that  is  applicable  to  that  step. 


Table  5-1.  Automation 

of  TRD  Tasks 

FUNCTION 

TYPE  OF  TASK 

CATEGORY 

DEVELOP  CONTRACT  PLAN 

CREATE 

M* 

REVIEW  CONTRACTUAL  REQUIREMENTS 

GATHER  &  REVIEW 

D 

CUSTOMER  SPECIFICATIONS 

GATHER  &  REVIEW 

D 

GATHER  RELATED  DATA 

GATHER 

D 

AVAILABLE  DATA 

COMPILE 

D 

RELATED  DESIGN  DOCUMENTS 

COMPILE  FROM  DESIGN 

D 

GENERATE  MISSING  DESIGN  DATA 

RESEARCH  &  DOCUMENT 

M* 

THEORY  OF  OPERATION 

REVIEW 

M* 

DEFINE  THEORY  OF  OPERATION 

DOCUMENT 

D 

GENERATE  MISSING  DATA 

COMPILE 

M* 

PHYSICAL  DESCRIPTION 

COMPILE  FROM  ENG. 

D 

NECESSARY  DATA 

EXTRACT  DATA 

D 

FORMAT  DATA 

DOCUMENT 

G 

M  -MANUAL  D  -DATA  BASE  S  -SIMULATOR  G 

-TRD  DOCUMENT  GENERATOR 

T  -TEST  STRATEGY  *  -DESIGN  RESPONSIBILITY 


Table  5-1.  Automation  of  TRD  Tasks  (Continued) 


ELECTRICAL  INTERFACE 
GET  DATA 
UUT  CONNECTOR  ID 
PIN  OUT  INFORMATION 
MECHANICAL  INTERFACE 
GET  DATA 

GENERATE  DRAWINGS 
SPECIAL  EQUIPMENT 
EQUIPMENT  DRAWINGS 
SPECIAL  TOOLS 

SPECIAL  TOOL  DRAWINGS 
TEST  DATA 
GET  DATA 
FORMAT  DATA 
BOILER  PLATE 
TRD  SHEETS 
TEST  DESIGN 

FUNCTIONAL  FLOW  CHART 
TEST  ISOLATION  STRATEGY 
FAULT  SIMULATION 
EVALUATE  RESULTS 
DETAILED  TEST  REQUIREMENTS 
DETAIL  FLOW 

DETAILED  CROSS  REFERENCE 
TEST  SHEETS 
FORMAT  DATA 
CREATE  ATLAS 
QA  PROVISIONS 

INSPECTION  OF  TRD 
QA  VALIDATION 

VALIDATE  TEST  PLAN 
TEST  EQUIPMENT 
PERFORM  TEST 
EVALUATION 


DEFINE  REQUIREMENTS 

M* 

COMPILE  FROM  ENG. 

D 

TRANSLATE/CROSS  REF 

G 

TRANSLATE/CROSS  REF. 

G 

DEFINE  REQUIREMENTS 

M* 

COMPILE  FROM  ENG. 

D 

COMP.  FROM  ENG. 

D 

REVIEW  ENG.  REQ. 

*!* 

COMP/TRANS 

D 

REVIEW/JUSTIFY 

M* 

COMPILE  DRAWINGS 

D 

GENERATE  TEST  PROC. 

T 

DEFINE  TESTS 

T 

TRANSLATE  TO  TRD 

G 

GENERATE  PAGES 

G 

TRD  PAGES 

G 

DEFINE  END  TO  END  TESTS 

T 

DEVELOP  FLOW  CHARTS 

G 

DEV  TEST  &  ISO.  STRAT 

T 

DETERMINE  FAULT  SIGNAT. 

S 

EVALUATE  SIMULATION 

T 

DEFINE  TEST  REQMTS. 

T 

DEV  TEST  FLOW  CHARTS 

G 

CHART/PROC  CROSS  REF 

G 

PREPARE  TEST  SHEETS 

G 

FORMAT  &  COMMENT 

G 

GENERATE  ATLAS 

G 

CHECK  CUST.  COMPLIANCE 

M 

CHECK  TRD  CONTENTS 

M 

EVALUATE  TESTS 

M 

CHECK  INPUT  TO  OUTPUT 

M 

CHECK  SPECIAL  TOOLS 

M 

RUN  TESTS 

M 

EVALUATE  TEST  RESULTS 

M 

The  investigation  of  specific  tools  application  to  the  tasks  identifiec 
required  analyzing  the  Tools  and  their  attributes  described  in  the  survey 
data,  literature,  and  matrices.  The  investigation  was  divided  into  major 
categories:  Testability,  CAE  workstations,  Computers  and  Peripherals, 
Simulators  and  TRD  generators.  The  investigation  provided  a  means  for 


estimating  when  the  automated  process  would  be  available  as  well  as  defining 
it's  probable  capabilities.  Appendix  D  contains  the  list  identifying  the  data 
included  in  the  analysis,  brief  description,  and  how  the  data  would  be  applied. 
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5.3  ACTIONS  REQUIRED  TO  IMPLEMENT  CHANGES 


Recommended  changes  can  be  divided  into  the  various  aspects  of  TRD 
automation  as  follows: 

1.  Modify  existing  Mi  I -Speci fication. 

2.  Develop  and  modify  TRD  process 

-  Hardware 

-  Software 

3.  Incorporate  emerging  tecnnol ogies. 

4.  Further  develop  simulators. 

5.3.1  Modify  Existing  Mil-Specification 

In  order  to  develop  the  TRD  automatical ly  early  in  tne  development  cycle, 
to  minimize  the  impact  on  design,  and  to  control  the  number  of  versions 
produced,  several  revisions  are  needed  to  MIL-STD-1 51 9. 

Provide  standardized  format  for  types  of  UUT  as  appendices  to  MIL-STD-1 51 9. 

-  TRDs  produced  automatically  will  provide  a  standardized  format  based  on 
the  type  and  level  of  UUT.  To  control  the  contents  of  the  TRDs, 
additional  page  formats  should  be  defined  which  will  include  complex 
signals,  mechanical  diagrams,  etc.  Standardized  formats  should  define 
the  method  for  accessing  and  transferring  data;  formatting  of  the  data; 
methods  for  modifying  the  approval  channels;  identify  central  reporting; 
how  to  interpret  the  data. 

Ennance  requirements  to  include  more  comprehensive  Theory  of  Operation. 


A  detailed  description,  with  taDles,  figures,  illustrations  and 
references  should  supplement  a  written  Theory  of  Operation  tecnnical 
description.  Tneory  of  Operation  can  become  essential  in  case  of  redesign, 
questionable  test  results,  substitution  of  stimuli  or  effects  of  stimuli 
sequences.  Page  formats  for  test  patterns  should  provide  areas  which  insure 
incorporation  of  adequate  signal  patterns,  drawings,  diagrams  needed  to  fully 
define  the  test  pattern  and  it's  application.  The  Tneory  of  Operation  page 
should  require  a  general  overview,  application  of  tne  UUT,  input,  output 
signals,  tneir  criticality  and  function,  symptoms  of  faulty  operation  and 
unusual  or  special  conditions  which  could  possibly  occur. 


The  TRD  snould  provide  complete  UUT  description  of  testing,  and  verify 
the  testability  of  tne  UUT  and  define  a  test  strategy  for  a  selected  set  of 
test  equipment  from  the  MATE  test  equipment  library.  By  requiring  the  use  of 
the  MATE  Automatic  Test  Equipment  library  it  will  identify  a  possible  ATE 
configurati on.  Equipment  included  in  the  MATE  library  has  ATLAS  commands 
which  will  enable  the  application  of  the  test  equipment  for  all  of  it's 
measurement  functions,  by  knowing  the  measurement  needed  for  a  test,  the 
capabilities  of  the  equipment,  and  the  ATLAS  commands  needed  to  exercise  the 
equipment,  a  library  of  ATLAS  subroutines  can  be  developed  and  used  to 
translate  TRD  specified  test  into  executable  test  routines.  MATE  is  specified 
to  control  known  set  of  equipment,  interfaces  and  ATLAS. 

Provide  requirement  for  executable  ATLAS  code  and  ATLAS  Test  Flow  Diagram 

-  The  generation  of  now  executable  ATLAS  code  and  Test  Flow  Diagrams 
represents  a  duplication  of  information  in  that  the  same  data  is 
presented  in  two  forms.  This  problem  can  be  overcome  in  two  ways: 

1.)  Eliminate  ATLAS  code  from  the  TRD  or  2.)  develop  an  executable 
ATLAS  code.  In  order  to  produce  executable  ATLAS  code,  activities 
currently  performed  as  a  part  of  the  TPS  must  be  done  as  a  part  of  the 
TRD.  Areas  involved  relate  to  preliminary  selection  of  ATE  equipment, 
applying  an  Automated  Test  Strategy  program  and  providing  additional 
data  to  the  test  program  developed.  These  efforts  must  be  defined  in 
tne  TRD  and  TPS  specification. 

Define  standard  interface  requirement  for  ATRDG  shell. 

THE  ATRDG  shell  must  perform  the  following  functions: 

1.  Reside  on  tne  CAE  and  be  callable  at  any  time. 

2.  Automatically  access  and  search  data  base. 

3.  Transfer  data  to  a  local  data  base. 

4.  Select  optimum  simulator. 

5.  Transfer  data  to  and  from  one  or  more  simulators. 

6.  Integrate  data  from  simulators. 

7.  Determine  if  distributed  processing  should  be  used. 

8.  Distribute  tasks. 

9.  Operate  in  background  with  minimum  operator  participation. 

10.  Provide  operator  instruction,  menu  shortfall  lists  and  other 
output  data  related  to  TRD. 

11.  Provide  for  easy  addition  or  change  of  utilized  hardware  or 
software. 

12.  Operate  a  networked  system. 

13.  Perform  tasks  in  the  background  (transparent  to  the  operator). 

14.  Create  a  TRD. 

15.  Provide  for  control  and  protection  of  data. 

16.  Provide  for  modification. 

17.  3e  written  in  standard  source  language. 
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Provide  a  standardized  electronic  media  output  of  the  TRD, 
simulation  data,  and  possible  ATE  equipment,  will  allow  the  TRD  to 
be  expanded  and  become  the  documentation  of  TPS  activities.  This 
will  eliminate  duplicated  efforts  currently  required  as  a  part  of 
the  TRD  and  TPS.  This  approach  will  result  in  multiple  release  of 
the  TRD.  The  early  releases  will  be  usable  for  TPS  bidding,  UUT 
descriptions  a.'.d  interfaces,  and  later  releases  representing  a 
complete  documentation  of  the  UUT  tests.  By  preserving  the 
electronic  media  files  they  can  be  modified  and  used  for  development 
of  the  Technical  Order  without  duplicating  the  data  gathering, 
simulation,  description  of  test  procedures  already  defined.  The 
controlling  specifications  for  all  three  activities  will  be  impacted 
by  the  use  of  an  automated  approach. 


The  revised  Mil-Specification  must  define  and  control: 


The  content,  control,  approval  and  distribution  of  each  release  of 
the  TRD 


The  standardization  of  hardware  and  software  interfaces 


Tne  revision,  addition  and  summaries  for  each  release 


Tne  controlling  agency  responsible  for  the  integrity  of  the  TRD 


Tne  area  where  specification  deviations  are  permissible 


IMPLEMENTATION  OF  CHANGE  -  The  TRD  specification  changes  listed  above  are 
needed  for  an  automated  process.  These  techniques  could  be  applied  to  areas 
which  are  still  under  development.  By  redefining  a  specification  for 
automated  TRD  development  in  the  near  future  the  specification  would  also  act 
as  a  guide  for  the  development  of  the  automated  process. 


5.3.2  Develop  And  Modify  TRD  Process  Hardware 


Interface  CAE  networks  with  other  resources. 


Progressing  from  the  existing  configuration  which  consists  of  specialized 
simulators,  general  purpose  computers,  TRD  document  generators,  and  the  near 
future  system  which  is  centered  around  a  CAE  workstation  with  expanded 
computer  capabilities;  requires  utilizing  links  to  simulators  and  TRD  document 
generators.  All  of  the  technology  required  to  accomplish  this  configuration 
is  currently  in  use,  or  has  been  introduced  in  the  marketplace. 

Implementation  involved  purchasing  and  linking  the  resources.  Figure  5-1 
depicts  one  of  a  variety  of  combinations  which  could  provide  the  needed 
capabi 1 i ty. 
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Provide  link  to  a  large  variety  of  commercial  and  government  simulators 
via  gToBal  data  case  networks.  ~ 

The  hardware  configuration  recommended  for  the  future  configuration 
illustrated  in  Table  5-2,  is  a  networked  system  with  capabilities  far  beyond 
the  anticipated  needs  of  a  TRD  development.  However,  the  configuration  is 
required  to  provide  computational,  and  special  purpose  hardware  when  needed. 

Devel op  high-speed  main-frame  computer  and  hardware  simulators  for 
simulation  of  large  complex  circuits. 

Large  complex  circuits  require  high-speed  main-frame  computers  for 
simulation  and  the  possibilities  of  special  hardware  techniques  was  not 
established  in  this  program.  The  approach  considered  feasible  was  to 
anticipate  development  of  interfaces  and  standard  hardware  which  will  enable 
resource  selection  and  application  on  a  shared  basis.  As  networks 
capabilities  are  expanded  computer  services  will  be  available  on  a  rental  and 
contract  basis  allowing  utilization  of  hardware  which  could  not  be  justified 
for  TRD  development  effort. 

5.3.3  Develop  and  Modify  TRD  Process  Software 

Software  needed  to  develop  TRDs  on  CAE  system  requires  application  of  a 
variety  of  specialized  programs,  such  as  listed  in  matrices  are  readily 
available  and  currently  in  use.  The  near  future  system  will  use  existing 
software  with  the  only  improvements  needed  in  the  interface  area.  Software 
exists  for  the  digital,  analog  and  electro-mechanical  analysis;  networking, 
data  base  application,  AI,  testability,  document  generation  and  CAE.  With  the 
advent  of  the  32-bit  computer  for  tne  CAE  workstation  level  it  is  feasible  to 
use  large  varieties  of  software  and  provide  a  user  friendly  interface  to  all 
capabilities  needed  for  TRD  development.  Software  needed  to  accomplish  near 
future  goals  is  a  simple  modification  to  the  CAE  operating  software  that 
allows  additional  routines  to  be  used  and  some  special  purpose  interface 
routines  to  be  developed.  This  new  software  can  be  divided  into  the  following 
parts: 

Data  base  routine  to  access  logistics,  engineering  and  contract 
administration1 s  data  bases  (CALS,  etc.). 

Data  gathering  being  one  of  the  most  labor-intensive  area  automating  this 
activity  presents  several  problems.  The  data  gathering  activities  can  only  be 
automated  if  the  data  is  resident  in  a  data  base  and  the  operator  can  access 
it.  Engineering  and  Logistics  data  is  available  and  can  be  accessed  if  a 
routine  resides  in  the  data  base  program  to  allow  access.  Contract  data  and 
preliminary  design  data  may  be  available  but  should  be  already  known  by  the 
designer,  if  the  designer  is  responsible  for  TRD  development  he  can  insert  the 
needed  information  eliminating  the  need  to  gather  the  data  a  second  time. 

Resident  data  base  routines,  embedded  in  Logistics,  Engineering  and 
contract  data  bases  to  allow  the  CAE  station  access  to  specific  items  for  the 
Automated  Test  Requirement  Document  Generation. 


I 

I 

Develop  software  required  to  achieve  the  specified  interfaces  for  Data 
Base  and  TRD  output. 

Simulator/CAE  interface  program  to  allow  simulator  data  to  be  transferred 
to  the  CAE  workstation.  The  TRD  document  generator/CAE  workstation  interface 
to  allow  data  to  be  transferred  to  the  document  generator  for  output. 

Forms  of  the  above  programs  have  been  developed  and  are  used  to  accomplish 
some  of  these  tasks;  however,  tne  variety  of  computers  operating  systems  and 
source  code  has  created  a  need  for  different  routines  to  be  written  for  each 
application,  as  illustrated  in  the  data  base  matrix. 

Further  development  of  simulators  for  complex  digital,  analog,  hybrid  and 
electro-mechanical  uUTs. 


Anotner  labor  intensive  area  is  simulation  which  is  partially  automated. 
The  simulation  of  Analog,  Hybrid  and  EM  require  development  of  new 
techniques.  Some  capabilities  have  been  around  for  years  but  they  are  not 
widely  used  and  do  not  provide  the  fault  analysis  capabilities  required  for 
TRD  development.  This  area  requires  a  great  deal  of  future  study  such  as: 

Analog  Signal  Generator 

Analog  Fault  Analysis  Program 

Complex  Circuit  Analysis  Technique 

Data  transfer  between  the  existing  programs. 

Define  and  develop  the  executive  programs  to  create  the  ATRDG. 

TRD  development  on  a  CAE  station  is  closely  related  to  UUT  design  and  can 
best  be  accomplished  by  the  designer  with  an  automated  process. 

The  approach  best  suited  for  this  set  of  conditions  is  to  develop  a 
framework  program  which  will  provide  capabilities  listed  above  under 
"Interface  CAE  networks  with  other  resources". 

To  accomplish  these  items  standard  interfaces  should  be  created  which 
will  allow  large  quantities  of  existing  software  to  be  modified  to  interface 
with  the  standard.  New  software  should  be  written  with  the  standard  in  mind. 
Software  exists  which  allows  computers  with  different  operating  systems  to  be 
interfaced.  This  will  allow  special  purpose  haroware  and  software  to  be  used 
witn  a  minimal  amount  of  additional  programming. 

Resource  selection  includes  analyzing  the  task  being  performed  to 
identify  the  optimum  solution.  This  will  use  a  knowledge-base  approach  to 
evaluate  the  type  and  size  of  circuit  simulators  from  the  software  available; 
resource  workload;  effort  required  to  complete,  if  the  task  can  be  divided 
among  available  resources;  and  if  other  related  tasks  can  be  run  in  parallel. 

1.  Select  the  optimum  resource  available  for  the  specific  task. 

2.  Select  the  most  appropriate  simulator. 


3.  Allow  the  inclusion  of  commercial  hardware  and  software  as  it  is 
developed. 


4.  Perforin  all  required  tasks  witii  little  or  no  operator  intervention. 


5.  Develop  a  TRD  in  a  background  mode. 

5.3.4  Incorporate  Emerging  Technology 

Incorporate  expert  system  techniques  into  the  ATRDG  shell  and  simulation 

Artificial  Intelligence  is  currently  being  applied  by  Rockwell  to  the 
maintenance  cycle  on  the  (Central  Integrated  Test  System  (CITS))  Expert 
Parameter  System  (CEPS)  and  Expert  Missile  Maintenance  Aid  (EMMA)  programs. 

AI  is  also  being  successfully  applied  to  TRD  development  by  several 
companies.  By  including  these  techniques  to  the  automated  TRD  process,  TRD 
development  by  the  designer  is  feasible. 

Application  of  AI  (Expert  Systems)  techniques  can  reduce  operator 
involvement  in  the  resource  selection,  data  handling  and  test  sequencing 
required  for  the  TRD,  A I  is  being  used  to  perform  tasks  similar  to  B-1B,  EMMA 
and  other  current  military  contacts. 

To  develop  a  fully  Automated  TRD  Document  Generator  the  Application  of 
Expert  System  to  the  following  area  warrants  investigation. 

Data  Management 

Test  Strategy 

Resource  Selection 

Automatic  Pattern  Generation  of  Analog  and  Digital  (Sequential) 
Circuits 

5.3.5  Further  Development  of  Simulators 

Improve  automatic  pattern  generator  to  handle  sequential  circuits 

Interactive  pattern  generation  resulting  rom  the  analysis  of  results  from 
previous  steps  is  necessary  and  must  be  performed  rapidly  to  minimize 
simulator  time.  AI  techniques  may  provide  a  solution  to  this  problem. 

Enhance  simulation  capability  of  complex  digital,  analog,  hybrid  and 
electro-mechanical  IfUTs 

Analysis  techniques  used  for  simple  digital  circuits  do  not  work  well  in 
other  environments  due  to  the  signal  complexity  and  faults  which  cannot  be 
identified  as  simple  pass/fail  designators.  Long  run  times  required  for  most 
simulations  has  precluded  application  of  design  simulators  for  TRD 
development.  Approaches  such  as  those  used  for  testability  analysis  has  not 
developed  to  the  point  of  providing  test  patterns  but  is  an  area  which  can  be 
further  explored  as  a  feasible  application. 
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H2,  13,  J,  K) 

569.  Douglas  A  Vander  Heide,  "TAD  SALES  LITERATURE",  N/A,  01Jan87,  (A2,  B,  Cl, 
02,  E7,  G2,  H2,  13,  J,  K) 

570.  N/A,  "TDA  SALES  LITERATURE",  N/A,  01Jan87,  (A5,  B2,  B3,  B4,  B5,  Cl,  D2, 
E5,  G2,  H2,  13,  Jl ,  J2,  J3,  K) 

571.  N/A,  "SYSCAP  SALES  LITERATURE",  N/A,  01Jan87,  (A5,  B3,  Cl,  D2,  E5,  G2, 

H2,  13,  J2,  K) 

572.  N/A,  "SMART  SALES  LITERATURE",  N/A,  01Jan87,  (A2,  B,  Cl,  D3,  E3,  G2,  H2, 
13,  J,  K) 

573.  N/A,  "DORIS  SALES  LITERATURE",  N/A,  01Jan87,  (A3,  8,  Cl,  D3,  E2,  G2,  H2, 
13,  J6,  K) 

574.  N/A,  "CADSAL  SALES  LITERATURE",  N/A,  01Jan87,  (A5,  B,  Cl,  D2,  E5,  G2,  H2, 
13,  J,  K) 


575.  N/A,  "CAFIT  SALES  LITERATURE",  N/A,  01Jan87,  (A5,  B,  Cl,  D2,  E5,  G2,  H2, 
13,  J,  KJ 


APPENDIX  B 
MATRIX  DATA 


Tne  data  base  contains  items  gathered  during  the  Survey  phase  of 
the  contract.  This  data  was  assigned  sequential  numbers  and  filed  in  the 
order  received.  The  data  base  lists  key  elements  and  a  summary  for  each 
data  item.  Any  of  these  elements  can  be  selected  as  a  basis  for  sorting. 
Evaluation  of  the  data  by  sorting  this  limited  amount  of  information  was 
unsatisfactory;  therefore,  matrices  were  developed  which  contained  data 
base  items  that  were  judged  to  satisfy  the  basic  requirements  of  an 
automated  process  (ie.  compatible  hardware  &  software,  user  able  to 
modify  input,  output  and  control  of  the  software,  language  common  with 
other  needed  capabilities). 

The  areas  of  primary  Interest  were  cost,  value,  compatibility, 
resource,  effectiveness,  technology  limits,  and  CAD  applicability.  Data 
base  items  sometimes  discuss  specific  issues  which  had  to  be  related  to  a 
complete  description  of  a  method  before  an  evaluation  was  possible. 

When  seven  or  more  data  base  items  discussed  the  same  topic,  they 
were  listed  in  a  matrix  for  comparison  with  items  listed  in  other 
matrices.  By  using  a  matrix  it  was  possible  to  categorize,  compare  and 
analyze  information  contained  in  the  articles.  The  articles  usually 
discussed  a  key  feature  of  a  system.  Frequently  it  was  necessary  to 
group  information  from  several  articles  in  order  to  obtain  a  composite  of 
the  systems  capabilities. 

Based  on  the  aforementioned  criteria  a  matrix  for  AI  Simulator, 
Analog  Simulator,  CAE  Workstation  and  Digital  Simulator  was  developed. 

The  matrices  are  presented  below: 


A I  SIMULATOR 


REF  NO: 

AI  SIMULATOR: 

COMPANY: 

WORKSTATIONS: 

LANGUAGE: 

RULE  TYPES: 
PRODUCTION 
RULE  FIRING: 
REASONING, 

DESCRIPTION, 

FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 


1 

ART 

INFERENCE  CORP. 

SUN-3 ( UNIX ) ,  (LMI,  SYMBOLICS,  TI)  LISP  MACHINES, 
VAX (UN IX) 

LISP  C 

INFERENCE,  HYPOTHESIS,  CONSTRAINT,  BELIEF, 

FORWARD  &  BACKWARD  CHAINING,  HYPOTHETICAL 
FEATURE  &  LANGUAGE  INTEGRATION,  OBJECT 
EMBEDDED 

NON-MONOTONIC,  EXPLANATION,  FACTS  LISTS 
DECLARATIVE,  PROCEDURAL,  ASPECTS,  TYPES,  GRAPHICS 
60-80  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 


t 


MATRIX  DATA  CONTINUED 


jf 

.’S' 

v*' 

|w 

1 1 


'll* 

W 

V»! 


s 


REF  NO: 

AI  SIMULATOR: 

COMPANY: 

WORKSTATIONS: 

LANGUAGE: 

RULE  TYPES: 
PRODUCTION 
RULE  FIRING: 

FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 

REF  NO: 

A I  SIMULATOR: 
COMPANY: 
WORKSTATIONS: 
LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 
FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 

REF  NO: 

AI  SIMULATOR: 
COMPANY: 
WORKSTATIONS: 
LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 
FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 

REF  NO: 

AI  SIMULATOR: 
COMPANY: 
WORKSTATIONS: 
LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 
FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 


2 

KEE 

INTELLICORP 

(SYMBOLICS,  LMI,  TI,  PC,  XEROX)  LISP  MACHINES, 

VAX (UN  IX) 

LISP 

INFERENCE,  HYPOTHESIS,  CONSTRAINT,  BELIEF, 

FORWARD  &  BACKWARD  CHAINING,  OBJECT  DESCRIPTION, 
FEATURE  &  LANGUAGE  INTEGRATION,  EMBEDDED 
FACTS  LISTS,  ASSERTIONS,  NON-MONOTONIC,  EXPLANATION 
DECLARATIVE,  PROCEDURAL,  ASPECTS,  TYPES,  GRAPHICS 
60  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 


RULEMASTER 
RADIAN  CORP. 

SUN(UNIX),  APOLLO(UNIX) ,  VAX(UNIX),  IBM  PC  AT 
C 

INFERENCE,  PRODUCTION 
FORWARD  8,  BACKWARD  CHAINING 

ASSERTIONS,  FUZZY  LOGIC,  RULE  LEARNING,  EXPLANATION 
N  A 

1-17  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 

4 

DUCK 

SMART  SYSTEMS  TECH. 

IBM  &  VAX  MAINFRAMES,  IBM  PC  AT,  SYMBOLICS  MACHINES 
NLISP 

INFERENCE,  PRODUCTION 
FORWARD  &  BACKWARD  CHAINING 
ASSERTIONS,  NON -MONOTONIC,  EXPLANATION 
N/A 

6  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 


KNOWLEDGE  ENGINEERING  SYSTEM  II 
SOFTWARE  ARCHITECTURE  &  ENGINEERING 
IBM  PC/XT-AT,  VAX(UNIX) ,  APOLLO(UNIX) 

LISP,  C 

HYPOTHESIS,  PRODUCTION,  BAYESIAN 
FORWARD  &  BACKWARD  CHAINING 
FACTS  LISTS,  EXPLANATION 
DECLARATIVE,  ASPECTS 

4  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 


m 

li 

I 

if 


m 

m 


few 

is1 

Pi 


M 

$ 

| 

M 


m 

i 


MU 


MATRIX  DATA  CONTINUED 


REF  NO: 

AI  SIMULATOR: 
COMPANY: 
WORKSTATIONS: 
LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 
FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 

REF  NO: 

AI  SIMULATOR: 

COMPANY: 

WORKSTATIONS: 

LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 

FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 

REF  NO: 

AI  SIMULATOR: 
COMPANY: 
WORKSTATIONS: 
LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 

FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 

REF  NO: 

AI  SIMULATOR: 

COMPANY: 

WORKSTATIONS: 

LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 
FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 


6 

M.l 

TEKNOWLEDGE  CORP. 

IBM  PC/XT-AT 
C 

INFERENCE,  BELIEF 

BACKWARD  CHAINING,  LANGUAGE  INTEGRATION 
FACTS  LISTS,  EXPLANATION 
N  A 

5  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 

7 

S.l 

TEKNOWLEDGE  CORP. 

I3M  PC  AT,  SUN{UNIX ) ,  VAX(UNIX),  IBM/YM  MAINFRAME, 
LISP  MACHINES 
LISP  C 

INFERENCE,  PRODUCTION 

BACKWARD  CHAINING,  FEATURE  &  LANGUAGE  INTEGRATION, 
OBJECT  DESCRIPTION 
EXPLANATION 

DECLARATIVE,  PROCEDURAL,  TYPES 

25-45  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 

8 

PERSONAL  CONSULTANT  PLUS 
TEXAS  INSTRUMENTS 
TI  &  IBM  PC 
LISP 

PRODUCTION 

BACKWARD  CHAINING,  FEATURE  &  LANGUAGE  INTEGRATION, 
OBJECT  DESCRIPTION 
N  A 

GRAPHICS,  EDITORS,  MULTIPLE  WINDOWS,  RULE  SYNTAX 
3  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 

9 

KNOWLEDGE  CRAFT 
CARNEGIE  GROUP  INC. 

(SYMBOLICS,  LMI ,  TI,  &  OTHERS)  LISP  MACHINES, 
VAX(UNIX) 

LISP 

INFERENCE,  HYPOTHESIS,  PRODUCTION 

FORWARD  &  BACKWARD  CHAINING 

FACTS  LISTS,  NON-MONOTONIC,  EXPLANATION 

DECLARATIVE,  PROCEDURAL,  ASPECTS,  TYPES,  GRAPHICS 

50  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 


MATRIX  DATA  CONTINUED 


REF  NO: 

AI  SIMULATOR: 
COMPANY: 
WORKSTATIONS: 
LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 
FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 

REF  NO: 

AI  SIMULATOR: 
COMPANY: 
WORKSTATIONS: 
LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 
FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 

REF  NO: 

AI  SIMULATOR: 
COMPANY: 
WORKSTATIONS: 
LANGUAGE: 

RULE  TYPES: 

RULE  FIRING: 
FEATURES: 

FRAME  TYPES: 

COST: 

CAD  CAE  COMPATIBLE: 


10 

IN-ATE 

AUTOMATED  REASONING 

MACINTOSH  PC,  (LMI ,  SYMBOLICS)  MACHINES,  VAX(UNIX) 
ZETALISP,  C 

LAP LAC I AN  LEARNING,  DEMPSTER-SHAFER,  PRODUCTION 
LOGIC  MODELING 
NON-MONOTONIC 
N  A 

2.5-15  K 
YES 


STATE  OF  ART:  NEAR  FUTURE 
PROPRIETARY:  YES 


11 

NEXPERT-OBJECT 
NEURON  DATA 
IBM  PC  AT 
C 

PRODUCTION,  RULECLASSES 
FORWARD  AND  BACKWARD  CHAINING 
NON-MONOTONIC 
OBJECTS 

5  K  STATE  OF  ART:  NEAR  FUTURE 

NO  PROPRIETARY:  YES 

12 

DORIS  2.0 
ROCKWELL 

SYMBOLICS,  VAX  WORKSTATIONS 
COMMON  LISP 
INFERENCE,  PRODUCTION 
FORWARD  AND  BACKWARD  CHAINING 
DEPTH  FIRST  SEARCH 
OBJECTS 

PROPRIETARY  STATE  OF  ART:  NEAR  FUTURE 

NO  PROPRIETARY:  YES 


ANALOG  SIMULATOR 


REF  NO: 

ANALOG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 

INTERFACE: 

HARDWARE: 

COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COMPARISON: 


13 

DSPICE  (SPICE2) 

DAISY  SYSTEMS  CORP. 

NEWTON-RALPHSON,  LUWER/UPPER  DECOMPOSITION, 
TRAPEZOIDAL,  BACKWARD  EULER,  GAUSSIAN  ELIMINATION 
INTERACTIVE  &  BATCH 
VAX (UNIX) ,  LOGICIAN 
85  K  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

SPICE  2G.5 


MATRIX  DATA  CONTINUED 


REF  NO.- 

ANALOG  SIMULATOR: 
COMPANY : 

ALGORITHMS  USED: 


INTERFACE: 

HARDWARE: 

COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COMPARISON: 

REF  NO: 

ANALOG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 

INTERFACE: 

HARDWARE: 

COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COMPARISON: 

REF  NO: 

ANALOG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 


INTERFACE: 

HARDWARE: 

COST: 

CAD/ CAE  COMPATIBLE: 
SPICE  COMPARISON: 

REF  NO: 

ANALOG  SIMULATOR: 
COMPANY; 

ALGORITHMS  USED: 
INTERFACE: 

HARDWARE: 

COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COMPARISON: 


MSP  ICE  (SPICE2 } 

MENTOR  GRAPHICS  CORP. 

LOWER/UPPER  DECOMPOSITION,  TRAPEZIODAL, 
NEWTON-RALPHSON,  BACKWARD  EULER, 
GAUSSIAN  ELIMINATION 
INTERACTIVE 
APOLLO (AEGES) 

7.1  K  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

SPICE  2G.6 


MSIMON  (POWER  SPICE) 

MENTOR  GRAPHICS  CORP. 

TRAPEZOIDAL,  ITERATIVE  TIMING  ANALYSIS, 

LOWER/UPPER  DECOMPOSITION,  RELAXATION 
INTERACTIVE 
APOLLO(AEGES) 

17.1  K  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

FASTER 

16 

HSPICE 
CALMA  CO. 

LOWER/UPPER  DECOMPOSITION,  TRAPEZOIDAL, 
NEWTON-RALPHSON,  BACKWARD  EULER, 

GAUSSIAN  ELIMINATION 
INTERACTIVE  &  BATCH 
APOLLO( AEGES) 

15  K  STATE  OF  ART:  PRESENT 

PROPRIETARY:  YES 

SPICE2 

17 

SABER 

ANALOGY 

NEWTON-RALPHSON,  GEAR  2  INTEGRATION,  SPARSE  MATRIX 
INTERACTIVE  &  BATCH 

SUN(UNIX) ,  IBM(CMS) ,  VAX(UNIX,  VMS),  APOLLO( AEGES) 
9-65  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 

TEN  TIMES  FASTER 


MATRIX  DATA  CONTINUED 


Vl'i 


Si 

& 

& 

is 

t 

55 

•$ 

S*j 

56 

I 

( 

fi<.|J 

t£M 

M 


REF  NO.- 

ANALOG  SIMULATOR: 
COf4P  ANY: 

ALGORITHMS  USED: 


INTERFACE: 

HARDWARE: 
APOLLO(AEGES) , 

COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COMPARISON: 

REF  NO: 

ANALOG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 

INTERFACE: 

HARDWARE: 

COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COW  ARISON: 

REF  NO: 

ANALOG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 
INTERFACE: 

HARDWARE: 

COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COMPARISON: 

REF  NO: 

ANALOG ' S I MULATOR : 
COMPANY: 

ALGORITHMS  USED: 
SENSITIVITY, 

INTERFACE: 

HARDWARE: 

COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COWARISON: 


PRECISE  (SPICE2,  SPICE3) 

ELEC.  ENG.  SOFTWARE 

LOWER/UPPER  DECOMPOSITION,  TRAPEZOIDAL, 
NEWTON-RALPHSON,  BACKWARD  EULER, 
GAUSSIAN  ELIMINATION 
INTERACTIVE  &  BATCH 
SUN(UNIX),  IBM(CMS) ,  VAX(UNIX,  VMS), 


ELXSI 
10-70  K 
YES 
FASTER 


STATE  OF  ART: 
PROPRIETARY: 


NEAR  FUTURE 
YES 


SIMON  (POWER  SPICE) 

ECAD 

LOWER/UPPER  DECOMPOSITION,  TRAPEZOIDAL, 
ITERATIVE  TIMING  ANALYSIS 
INTERACTIVE  &  BATCH 

VAX(VMS) ,  APOLLO(AEGES),  SUN(UNIX),  ELXSI 
15-45  K  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 

FASTER 

20 

LSIM  (SMILE) 

SILICON  DESIGN  LABS 

ADEPT  TIMING,  E-LOGIC,  INTERACTIVE  INTEGRATION 
INTERACTIVE 

SUN(UNIX),  APOLLO(UNIX),  VAX(UNIX.VMS) 

40K  PER  STATION  STATE  OF  ART:  NEAR  FUTURE 

YES  PROPRIETARY:  YES 

FASTER 

21 

SYSCAP 

ROCKWELL 

DC-FAULT  ANALYSIS,  WORST  CASE,  PARAMETER 

MONTE  CARLO 
INTERACTIVE  &  BATCH 
VAX (VMS),  IBM (CMS),  CDC 
100K  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

FASTER 


Hil 


mil 


matrix  data  continued) 


m 

II 


m 


se 

li 


M 


REF  NO: 

ANALOG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 


INTERFACE: 

HARDWARE: 

PC  AT 
COST: 

CAD/CAE  COMPATIBLE: 
SPICE  COMPARISON: 


ANALOG  WORKBENCH SPICE3) 

ANALOG  DESIGN  TOOLS 

DC  OPERATING  POINT,  NONLINEAR  TRANSIENT, 

FAST  FOURIER  TRANSFORM,  NOISE  FACTOR,  LINEAR  AC, 
DC  SWEEP 
INTERACTIVE 

SUN(UNIX) ,  HP90Q0-320( UNIX) ,  APOLLO ( AEGES ) ,  IBM 


SPICE3  COMPATIBLE 


CAE  WORKSTATION 


STATE  OF  ART:  PRESENT 
PROPRIETARY:  YES 


REF  NO: 

23 

CAE  WORKSTATION: 

DOMAIN  3000 

COMPANY: 

APOLLO  COMPUTER  INC. 

CENTRAL  PROCESSOR: 

68020 

LOCAL  MEMORY: 

2-4  M 

HARD  DISK:  72  M 

CLOCK  RATE: 

16.6  MHZ 

GRAPHIC  SUPPORT:  YES 

PROPRIETARY: 

YES 

COST:  30  K 

AUTO  FAULT  SIMULATION: 

NO 

MULTI  USERS: 

REF  NO: 

24 

CAE  WORKSTATION: 

VAXSTATION  II 

COMPANY: 

DIGITAL  EQUIP  CORP. 

CENTRAL  PROCESSOR: 

MICROVAX  II 

LOCAL  MEMORY: 

2-8  M 

HARD  DISK:  31-71  M 

CLOCK  RATE: 

16.6  MHZ 

GRAPHIC  SUPPORT:  NO 

PROPRIETARY: 

YES 

COST:  21.6  K 

AUTO  FAULT  SIMULATION: 

NO 

NO.  USERS:  1-40 

REF  NO: 

25 

CAE  WORKSTATION: 

RT -61 50 /I 

COMPANY: 

IBM  CORP. 

CENTRAL  PROCESSOR: 

RISK 

LOCAL  MEMORY: 

1-4  M 

HARD  DISK:  40-210  M 

CLOCK  RATE: 

5.8  MHZ 

GRAPHIC  SUPPORT:  NO 

PROPRIETARY: 

YES 

COST:  20-50  K 

AUTO  FAULT  SIMULATION: 

NO 

NO.  USERS: 

REF  NO: 

26 

CAE  WORKSTATION: 

3/260M 

COMPANY: 

SUN  MICROSYSTEMS  INC. 

CENTRAL  PROCESSOR: 

68020 

LOCAL  MEMORY: 

8-32  M 

HARD  DISK:  60-560  M 

CLOCK  RATE: 

20  MHZ 

GRAPHIC  SUPPORT:  YES 

PROPRIETARY: 

YES 

COST:  51-84  K 

AUTO  FAULT  SIMULATION: 

NO 

NO.  USERS: 

MATRIX  DATA  CONTINUED 


REF  NO: 

27 

CAE  WORKSTATION: 

LOGICIAN 

COMPANY: 

DAISY 

CENTRAL  PROCESSOR: 

80286,  80287 

LOCAL  MEMORY: 

2-16  M 

HARD  DISK: 

40-140  M 

CLOCK  RATE: 

20  MHZ 

GRAPHIC  SUPPORT: 

YES 

PROPRIETARY: 

YES 

COST: 

20  K 

AUTO  FAULT  SIMULATION: 

YES 

NO.  USERS: 

1-2 

REF  NO: 

28 

CAE  WORKSTATION: 

HP90Q0  MODEL 

320 

COMPANY: 

HEWLETT  PACKARD  CO. 

CENTRAL  PROCESSOR: 

68020 

LOCAL  MEMORY: 

1-7.5  M 

HARD  DISK: 

16-4000  M 

CLOCK  RATE: 

16.6  MHZ 

GRAPHIC  SUPPORT: 

YES 

PROPRIETARY: 

YES 

COST: 

20-40  K 

AUTO  FAULT  SIMULATION: 

NO 

NO.  USERS: 

25 

REF  NO: 

29 

CAE  WORKSTATION: 

IDEA  1000 

COMPANY: 

MENTOR  GRAPHICS  CORP. 

CENTRAL  PROCESSOR: 

32  BIT  VLSI 

LOCAL  MEMORY: 

2-4  M 

HARD  DISK: 

50-167  M 

CLOCK  RATE: 

16.67  MHZ 

GRAPHIC  SUPPORT: 

YES 

PROPRIETARY: 

YES 

COST: 

28-77  K 

AUTO  FAULT  SIMULATION: 

NO 

NO.  USERS: 

REF  NO: 

30 

CAE  WORKSTATION: 

SCALDSYSTEM 

COMPANY: 

VALID 

CENTRAL  PROCESSOR: 

68020 

LOCAL  MEMORY: 

12  M 

HARD  DISK: 

2000  M 

CLOCK  RATE: 

GRAPHIC  SUPPORT: 

YES 

PROPRIETARY: 

YES 

COST: 

35-1 70K 

AUTO  FAULT  SIMULATION: 

NO 

NO.  USERS: 

16 

REF  NO: 

31 

CAE  WORKSTATION: 

CAE  2000 

COMPANY: 

TEKTRONIX 

CENTRAL  PROCESSOR: 

78032 

LOCAL  MEMORY: 

1-4  M 

HARD  DISK: 

31-71  M 

CLOCK  RATE: 

16.7  M 

GRAPHIC  SUPPORT: 

YES 

PROPRIETARY: 

YES 

COST: 

34.5-90  K 

AUTO  FAULT  SIMULATION: 

NO 

NO.  USERS: 

1-200 

MATRIX  DATA  CONTINUED 


REF  NO.- 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 
SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 

REF  NO: 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 
SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 

REF  NO: 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 

SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 

dff  wn- 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 


SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

OPUS, 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 


DIGITAL  SIMULATOR 


32 

TCAT  (TEGAS  5) 

CALMA  CO. 

FAULT  COLLAPSING,  STUCK  AT  FAULT 
P&RAI  I  FI 

INTERACTIVE  &  BATCH 
APOLLO(AEGES),  VAX (VMS),  IBM  PC/XT-AT 
20-40  K  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

EVENTS  PER  SECOND:  2000 


33 

DAISY  LOGIC  SIM 
DAISY  SYSTEMS  INC. 

FAULT  COLLAPSING,  STUCK  AT  FAULT 

CONCURRENT 

INTERACTIVE  &  BATCH 

IBM  PC/AT,  VAX (UNIX) ,  LOGICIAN,  IBM(CMS) 
5b  K  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

YES  EVENTS  PER  SECOND:  3-100  K 


34 


TEST  GRADE 
GATEWAY  DESIGN  AUTO 

EQUIVALENT  FAULT  SUBSETS,  STUCK  AT  FAULTS, 
BACKTRACING  &  FORWARD  PATH  SENSITIZATION 


CONCURRENT 
INTERACTIVE  &  BATCH 

APOLLO(AEGES),  IBM(MVS,  CMS),  SUN(UNI),  VAX(VMS) 
ELXSI 


35-150  K 

STATE  OF  ART.- 

PRESENT 

YES 

PROPRIETARY: 

YES 

YES 

EVENTS  PER  SECOND: 

35 

HILO-3 

GENRAD 

5-STATE, 

15-VALUE  LOGIC  STRENGTH,  CAMELOT, 

PARALLEL  VALUE  LIST,  AUTOMATIC  TEST  PATTERN 
GENERATION  USING  CRITICAL  PATH  TECHNIQUES 
PARALLEL  &  CONCURRENT 
INTERACTIVE  &  BATCH 

VAX,  APOLLO,  IBM,  SUN,  RIDGE,  HP9000,  ELXSI, 


» 


VALID 

12-160  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

YES  EVENTS  PER  SECOND:  3000 


MATRIX  DATA  CONTINUED 


REF  NO.- 

36 

DIG  SIMULATOR: 

CADAT  5 

COMPANY: 

HHB  SOFTRON 

ALGORITHMS  USED: 

BACKTRACING 

,  FAULT  COLLAPSING, 

STUCK  AT  FAULTS, 

MODEL  SOURCE  CODES,  DETECTS  4 

SUPPRESSES 

FAULTS 

SIMULATION  TECHNIQUE: 

CONCURRENT 

USER  INTERFACE: 

INTERACTIVE 

4  BATCH 

HARDWARE: 

APOLLO,  SUN 

,  IBM  PC/XT-AT,  VAX 

,  DATA  GENERAL 

COST: 

3-80  K 

STATE  OF  ART.- 

PRESENT 

ATE  INTERFACE: 

YES 

PROPRIETARY: 

YES 

CAD/CAE  COMPATIBLE: 

EVENTS  PER  SECOND: 

1000 

REF  NO: 

37 

DIG  SIMULATOR: 

SILOS,  PC=(PSILOS ) 

COMPANY: 

SIMUCAD 

ALGORITHMS  USED: 

FAULT  COLLAPSING,  INPUT  4  OUTPUT  STUCK  AT 

FAULTS 

FAULT  BLOCKING,  STATISTICAL  FAULTING 

SIMULATION  TECHNIQUE: 

CONCURRENT 

USER  INTERFACE: 

INTERACTIVE 

4  BATCH 

HARDWARE: 

APOLLO(AEGES,  UNIX),  SUN(UNIX) 

,  IBM(CMS)  4  PC/AT 

VAX( VMS,  UNIX) 

COST: 

3-125  K 

STATE  OF  ART: 

PRESENT 

ATE  INTERFACE: 

YES 

PROPRIETARY: 

YES 

CAD/CAE  COMPATIBLE: 

YES 

EVENTS  PER  SECOND: 

1500 

REF  NO: 

38 

DIG  SIMULATOR: 

MACH  1000 

COMPANY: 

SILICON  SOLUTION 

ALGORITHMS  USED: 
SIMULATION  TECHNIQUE: 

CONCURRENT 

USER  INTERFACE: 

INTERACTIVE 

4  BATCH 

HARDWARE: 

ETHERNET  SERVER  INTERFACE 

COST: 

120K-1M 

STATE  OF  ART: 

NEAR  FUTURE 

ATE  INTERFACE: 

YES 

PROPRIETARY: 

YES 

CAD/CAE  COMPATIBLE: 

YES 

EVENTS  PER  SECOND: 

1M 

REF  NO: 

39 

DIG  SIMULATOR: 

HELIX 

COMPANY: 

SILVER  LISCO 

ALGORITHMS  USED: 
SIMULATION  TECHNIQUE: 

CONCURRENT 

USER  INTERFACE: 

INTERACTIVE 

4  BATCH 

HARDWARE: 

APPOLO  (AEGES.UNIX),  IBM  PC/RT  4  RISC,  VAX 

(VMS), 

PRIME 

COST: 

20K-40K 

STATE  OF  ART: 

PRESENT 

ATE  INTERFACE: 

YES 

PROPRIETARY: 

YES 

CAD/CAE  COMPATIBLE: 

YES 

EVENTS  PER  SECOND: 

450 

MATRIX  DATA  CONTINUED 


REF  NO: 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 


SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 


40 

LMSAR6 

TERADYNE 

EQUIVALENT  FAULT  REMOVAL,  STUCK  AT  FAULTS,  MODEL 
SOURCE  CODING,  DETECTS  &  SUPPRESSES  FAULTS, 
BACKTRACING 
CONCURRENT 
INTERACTIVE  &  BATCH 
VAC  (VMS),  APPOLLO  (AEGES) 

50-280K  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

YES  EVENTS  PER  SECOND:  500-600 


REF  NO: 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 

SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 


41 

FSIM  (QUICKSIM) 

MENTOR  GRAPHICS  INC. 

EQUIVALENT  FAULT  COLLAPSING  REMOVAL,  STUCK  AT 
FAULTS,  DETECTS  &  SUPPRESSES  FAULTS,  IDEA 
CONCURRENT 
INTERACTIVE  &  BATCH 
APPOLLO  (AEGES),  VAX(VMS) 

17.9-40K  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

YES  EVENTS  PER  SECOND: 


REF  NO: 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 
SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 


42 

VALIDSIM 

VALID  LOGIC  SYSTEMS 

USES  A  FAULT  GRADING  TECHNIQUE 

CONCURRENT 

INTERACTIVE  &  BATCH 

VAX (VMS, UNIX),  IBM  PC/AT  &  (CMS),  SCALDSYSTEM 
7 OK  STATE  OF  ART:  PRESENT 

YES  PROPRIETARY:  YES 

YES  EVENTS  PER  SECOND: 1200 


REF  NO.- 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 
SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 


43 

HITS 

NAVAIRENGCEN 

SET-INlERSECTION,  STUCK  AT  FAULTS 
CONCURRENT 
INTERACTIVE  &  BATCH 
VAX(VMS.UNIX) 

230  STATE  OF  ART:  PRESENT 

NO  PROPRIETARY:  NO 

NO  EVENTS  PER  SECOND: 


i-1  ATKIX  DATA  CONTINUED 


REF  NO: 

DIG  SIMULATOR: 
COMPANY: 

ALGORITHMS  USED: 
SIMULATION  TECHNIQUE: 
USER  INTERFACE: 
HARDWARE: 

COST: 

ATE  INTERFACE: 

CAD/CAE  COMPATIBLE: 


44 

TDA 

ROCKWELL 

PIN  TO  PIN  SHORTS,  HIGH-RAIL  (SELECTABLE  VOLTAGE) 
SERIAL 

INTERACTIVE  &  BATCH 
VAX (VMS) 

80K  STATE  OF  ART:  PRESENT 

NO  PROPRIETARY:  YES 

NO  EVENTS  PER  SECOND: 


APPENDIX  C 

STATE  OF  THE  ART  COMPUTER  TOOLS 

Following  are  tools  identified  in  the  survey  analysis.  The 
numoer  following  the  "Name"  in  parenthesis  refers  to  the  literature 
reference  number  in  Appendix  A. 


DESCRIPTION 


COMPANY 


ADEPT  (522)  Analog  Design  Tool  for  automatic 
dynamic  electrical  partitioning 
of  transistors 

AFCAD  (567)  Wordprocessor  office  automation 
ANGEL  (310)  An  automatic  logic  synthesizer 
for  integrated  VLSI  design 
systems 

ANSYS  (567)  Provides  finite  element 
analysi s 

ARCIS  (71 )  A  simulator  for  those  developing 
gate  arrays 

BILBO  (136)  Integrates  Scan  Path  Design 
with  signature  analysis. 
Registers  output  pseudorandom 
patterns  to  test  combinational 
logic  circuits 

BIST  (4,  5)  Hardware  Generated  Tests 
BITGRADE  (545)  Fault  Simulator-determines 
fault  grades  of  many  digital 
test  patterns 

BOXER  (567)  3D  Solids  Modeler 

CADAT  (53,  70,  71,  74,  164,  313,  315,  323, 

561 )  A  12-state  Di gital 
Simulator  which  carries  9 
additional  internal  states 
CAFIT  (575)  Testaoility  Analyzer  which 
provides  a  figure  of  merit 
CADSAL  (574)  System  Analysis  Tool 
CAL-MP  (567)  LSI  Layout 
CATS  (8,  313)  All  purpose  logic  &  fault 
simulator 

CAMElOT  (65,  304,  3 17,  523)  A  Computer  Aided 
Measure  of  Logic  Testability, 
tnis  algorithm  provides 
normalized  values  for 
control  ability  &  observability 


AFCAD  (567) 
ANGEL  (310) 


ANSYS  (567) 
ARCIS  (71) 
BILBO  (136) 


Auto-Trol 


Auto-Trol 

Matra  Design 
Systems 


Gateway  Design 


Auto-Trol 

HHB 


CAFIT  (575) 


CATS  (8,  313) 


Rockwel 1 

Auto-Trol 

HHB 

Sears  Com 
Computers 


m 


COMET  (523)  Modified  version  of  SCOAP  for 
semicustom  designs 

COP  (53,  55,  423)  Algorithm  for  Testability  Bell  Northern 
with  random  patterns 

COPTR  (55,  304)  Testability  based  on  SCOAP  Calma 
which  serves  as  a  pathfinder 
for  automatic  test  generation 
programs 

CVT-FERT  (418)  A  transistor  level  fault 

simulator  which  handles  dynamic 
&  static  memory  conditions  as 
well  as  oscillations  and  races 


DAISY 

LOGIC 

SIMULATOR  (71,  313,  323) 

A  logic  simulator  which  carries 
internal  &  external  states 

Daisy 

DIANA 

(567) 

IC  Simulation 

Auto-Trol 

DORIS 

(573) 

AI  shell  written  in  LISP  on  a 
Symbolics  computer 

Rockwel 1 

DTA  (154,  185,  337,  357,  560)  CAE 

Testability  based  on  SCOAP 
using  test  point  selection 

Daisy 

EMTP 

(567) 

Electromagnetic  Transient 
Simulator 

Auto-Trol 

FAN  (3b0,  423)  A  automatic  Test  Pattern 
Generator  whicn  uses 
concurrent  simulation  of  large 
digital  circuits  (  |10K  gates  ) 

FANSIM3  (426)  Simulates  complex  digital 

circuits  at  gate  &  functional 
level s 

FSIM  (53,  559)  Concurrent  Functional  Fault  Mentor 
Simulator-  enhanced  version  of  Graphics 
CADAT  fault  simulator 

GARDS  (567)  GARDS  Gate  Array  Design  Auto-Trol 

HAL  (321)  A  high  speed  logic  simulation  NEC  Corp 
machine  which  applies  hardware 
implementation,  parallel 
processing  &  pipeline 
processing 

HDL  (SYNTHESIS)  (421)  A  hardware  description  GenRad 
language  in  digital  systems 
testing/verification 

HILO  (53,  164,  296,  313,  318,  323,  325,  390,  GenRad 
412)  A  15  state  concurrent 
logic  fault  simulator  which 
uses  a  hybrid  parallel- 
concurrent  algorithm 


HITAP  (55,  523)  Testability  Analysis  Program  GenRad 
which  provides  ratings  for 
observabi 1 i ty  &  controlability 
to  determine  specific  test 
points  in  a  design 

HITEST  (39,  335)  A  test  generation  program  GenRad 
which  uses  knowledge 
engineering  through  a  parallel 
value  list  technique 

HITS  (162,  285,  289)  Digital  Simulator,  a  Navy/Air  Force 
hierarchical  integrated  test 
simulator  modeling  language 

TN-ATE  ('186,  460)  Provides  expert  rules  IN-ATE 

specifying  fault  diagnosis  for 
mechanical  troubleshooting 

LASAR  (53,  70,  164,  323,  557)  15-state  Gate,  Teradyne 
RAM,  ROM,  Concurrent  digital 
fault  simulator  witn  Time 
Windows 

LISP  (63,  241,  234,  340,  438)  A  symbolic  AI 
Language  which  comes  with 
powerful  document  management 
tools 

LOGICPRO  (71)  A  logic  simulator  which  works  E/Z  CAD 
at  the  switch  and  gate  level, 
includes  CMOS  &  TTL  logic 
primitives  E/Z  CAD 
level 

LOGOS  (428)  Improves  Automatic  Test  Grumman 

Generation  of  Digital  Circuits 

LOGMOD  (151,  406)  Testability  Analyzer,  Detex 

automatically  generates  the 
optimal  fault  paths 

MATE/ATLAS  (187,  262,  270,  281)  Test  Program  Air  Force 
Language,  ease  of  movement  of 
a  TPS  from  one  tester  to 
another  through  ATLAS 

MENTOR  (201,  205,  207,  559)  CAE  Programs,  Mentor 
compute  engine  accelerator 

MSC/NASTRAN  (567)  Finite  Element  Analysis  AUTO-TROL 

PAFEC  (567)  Finite  Element  Analysis  AUTO-TROL 

PASA  (567)  Power  Flow  AUTO-TROL 

PATRAN-G  (567)  Mechanical  Design  &  Analysis  AUTO-TROL 

PAWS  (294,  568)  TRD  Developer  Program,  TYX 

provides  the  capability  to 
automate  the  generation  of 
TPS  documentation 

PC-LOGS  (71)  A  logic  simulator  which  is  part  Personal  CAD 
of  a  schematic-capture  system  Systems 

targeted  at  gate  array  design 


PODEM  (33b,  350)  Patn  Oriented  Decision 

Making  Algorithm  -  accelerates 
tne  test  pattern  generation  for 
error  correction  and  translator 
circuits 

RIM  (471 )  Relational  Information  Boeing 

Management  System  data  base 

ROMULUS  (567)  3D  Design  &  Analysis  AUTO-TROL 

RTL  (162,  285,  304,  317,  366,  419)  Register 
Transfer  Language 

SCOAP  (55,  429,  523,  527)  Sandia 

Co  n  tro  1  ab  i  1  i  ty /Ob  serva  bi  1  i  ty 
Analyses  Provides  6  measurement 
values 

SDS  (567)  VLSI  Design  AUTO-TROL 

SILOS  (71 )  Microcomputer  simulator  which  Simutec 
isn't  currently  tied  directly 
to  any  PC-based  schematic 
capture  package 

SIMUL06  (71)  Logic  simulator  which  accepts  Chancellor 
almost  every  ILOGS  or  SILOS  Computer 

type  format 


SPICE  (68,  132,  198,  321,  322,  326,  370,  UC  Berkeley 
415,  476,  482,  483,  484,  522) 

Analog  Simulator,  Provides 
circuit  analysis  and  simulation 
at  the  electronic  component 
level 

SPLICE  (68,  4U9,  522)  Uses  iterated  timing  UC  Berkeley 
STAFAN  (55,  304)  AT&T  BELL 

Uses  test  vectors  to  calculate 
Control abi 1 i ty/Observaoi 1 i ty 
STAMP  (152,  407)  Conducts  testability  ARINC 

analysis  &  develops  fault 
isolation  strategies  for  Digital 
Analog,  Electro-Mechanical  & 

Hybrid  Systems 

STATGRADE  (545)  Digital  Fault  Analysis  using  Gateway  Design 
statistics 

SUPERCOMPACT  (567)  Microwave  Design  AUTO-TROL 

SYSCAP  (571)  Analog  Simulator  with  DC-fault  Rockwell/CDC 
analysis  for  SRU  &  component 
level  testing 

T  (567)  Derivative  of  LISP  -  AI  Language  AUTO-TROL 
TAD  (569)  TRD  Development  Program  D.  Vanderhide 

TAGS  (557)  Technology  for  the  Automatic  Teradyne 

Generation  of  Systems 


TAS  (567)  Thermal  Analysis 
TEGAS  (164,  171,  323)  4-state  gate  & 

functional  Digital  Simulator 
TESTGRADE  (545)  Interactive  logic  & 

concurrent  Fault  Simulator 
TESTSCAN  (545)  Automatic  SCAN  Test  Generator 
for  digital  circuits 
TRIFLEX  (567)  Piping  Design  &  Analysis 
TDA  (570)  Hybrid,  Digital,  &  Analog 
fault  simulator 

TEST  (433)  Computer  Aided  Test  Analysis 
system  to  detect  and  isolate 
faults 

THEMIS  (54,  164)  Concurrent  Fault  Simulator 
Hierarchical ,  event  driven, 
multi-level,  interactive, 
logic  simulator,  for  switch, 
logic,  register  transfer, 
functional  &  behavioral  levels, 
for  LSI  VLSI  &  PC  10  state, 

10X  parallel  speed 

VALIDATION  DESIGNER  (323,  343,  545)  CAE 
System  simulator  &  hardware 
modeler 

VERILOG  (323,  343,  545)  Mixed  Level  Hardware 
Description  Language 
LOGIC  EVALUATOR  (53,  164,  213)  Digital 
Hardware  Simulator  with  a 
concurrent  algorithm 


AUTO-TROL 

GE 

Gateway  Design 

Gateway  Design 

AUTO-TROL 
Rockwel 1 

Prime 

Valid 

Gateway  Design 
Zycad 
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MISSION 

of 

Rome  Air  Development  Center 

RA  VC  plan s  and  executes  research ,  development,  test 
and  selected  acquisition  programs  In  support  o f 
Command,  Control,  Communications  and  Intelligence 
'C77!  activities.  Technical  and  engineering 
support  wrthrn  areas  of  competence  rs  provraea  Co 
ESV  Program  Calces  IPOs]  and  other  ESV  elements 
to  perform  elective  acquisition  of  C3 1  systems. 

The  areas  0  f  technical  competence  Include 
communications ,  command  and  control,  battle 
management,  Information  processing,  surveillance 
sensors,  Intelligence  data  collection  and  handling, 
ic ’lid  state  sciences,  electromagnetics ,  and 
propagation,  and  electronic,  maintainability , 
and  compatlb lllty . 


